Traditional load balancing technologies enable incoming traffic to be routed to one or more SharePoint web servers. The amount of intelligence applied to these routing actions varies in scope from the most rudimentary types of routing (such as DNS round-robin) to advanced routing as seen in dedicated load balancing solutions.
Although it is possible to configure an external load balancer to understand the specific behaviors required for a SharePoint environment, such solutions can have shortcomings:
■■ Changes made at the load balancer level can have dramatic effects on the SharePoint farm, resulting in inconsistencies or outages.
■■ Changes made within the SharePoint farm but not reflected in the load balancer configuration (such as search crawler changes) can have a negative effect on performance.
For instance, consider a SharePoint farm that is both serving user requests and search crawls at the same time. Enough search requests might cause the SharePoint environment to have increased latency serving user requests; such a situation could result in a perceived outage, causing irregular work stoppages.
MORE INFO CONFIGURING REQUEST MANAGER
There are several different ways in which Request Management can be configured. These configurations are discussed in the TechNet article “Configure Request Manager in SharePoint Server 2013” at http://technet.microsoft.com/en-us/library/jj712708.aspx.
Request Management versus throttling
Earlier versions of SharePoint included the notion of HTTP request throttling, in which the current state of each web server was evaluated, and incoming requests could be throttled before a server reached a nonresponsive status. The current health of a web server could be observed in the HTTP response within a header called X-SharePointHealthScore.
Request Management is a new form of intelligent request routing and throttling available within SharePoint 2013. Request Management can be enabled on a per web-application basis, enabling incoming requests to be evaluated against a set of rules to determine which web server (if any) will respond.
Deployment modes
There are two deployment modes for request management: dedicated and integrated.
Dedicated mode deployments are useful in larger environments and allow for the segmentation of request management activities away from the web servers servicing the requests.
In an integrated mode deployment, request management is handled directly on the web servers, meaning that any server running the SharePoint Foundation Web Application Service also has the Request Management service instance provisioned.
Throttling rules
An incoming HTTP request will first be evaluated by the throttling rules; if an incoming request matches a throttling rule, the request is refused immediately.
Throttling rules also have a couple of other options worth noting: Expiration and Threshold. The Expiration option enables you to set an expiration date and time for the rule; the Threshold option enables you to automatically remove a routing target (web server) if the health score exceeds the value you select (health scores from 0 to 10).
| EXAM TIP |
| Unless otherwise specified, throttling is enabled by default on each web app created in the |
| farm. |
Throttling rules can be enabled or disabled using the -ThrottlingEnabled parameter of the Set-SPRequestManagementSettings cmdlet. Additional configuration for the throttling rules can be administered using the Get-/Set-SPThrottlingRule PowerShell cmdlet.
Routing rules and execution groups
Next to be evaluated are routing rules. These rules are accumulated into a series of three execution groups (0, 1, and 2). Group 0 is the highest level (evaluated first), followed by groups 1 and 2.
There are a couple of rather important things to know about execution group behavior:
■■ Routing rules that are not associated with an execution group are automatically associated with execution group 0.
■■ If an incoming request is matched by a rule within an execution group, no further rules or groups are evaluated and the request is routed and prioritized.
Unless otherwise specified, routing is enabled by default on each web app created in the farm.
Routing rules can be enabled or disabled using the -RoutingEnabled parameter of the SetSPRequestManagementSettings cmdlet. Additional configuration for the throttling rules can be administered using the Get-/Set-SPThrottlingRule PowerShell cmdlet.
There are no PowerShell cmdlets for working with execution groups because they are configured along with the creation/administration of routing rules.
Rule syntax
Rules control the evaluation criteria for the throttling, prioritization, or routing of incoming HTTP requests. The criteria for each rule consist of match properties, match types, and match values. Each rule chooses a match property, assigns an operator to it, and then assigns a value for the match.
IMPORTANT THROTTLING AND ROUTING RULE SYNTAX
The syntax used for these rules is identical for both throttling and routing.
There are eight types of match properties that specify an HTTP header for the match values:
■■ CustomHeader
■■ Host
■■ HttpMethod
■■ IP
■■ SoapAction
■■ Url
■■ UrlReferrer
■■ UserAgent
There are four associated operators for the match:
■■ RegEx
■■ Equals
■■ Starts with
■■ Ends with
Rules criteria can be administered using the New-SPRequestManagementRuleCriteria cmdlet. This cmdlet enables an administrator to set the match properties, match types, and match values for throttling or routing rules.
Routing targets
Any machine running the SharePoint Foundation Web Application Service is a potential routing target (a machine that could service incoming HTTP requests). An appropriate server is selected via one of two weighting schemes: static- or health-weighted.
Static-weighted routing enables an administrator to predefine which servers will be more or less able to serve requests. This weighting is set by fault to a value of 1; changing this value to a lower integer value (say 0 or –1) will cause a server to be utilized less; changing the value to an integer value greater than 1 would cause a server to be considered “stronger” and thus more utilized.
For instance, in an environment in which servers are being refreshed (older servers being replaced by newer servers), the SharePoint web servers might not be identical in hardware configuration or resources. In such a situation, it might be preferable to assign a higher weight to a server with more resources while assigning a lower weight to a server that is older or less able to serve requests.
Unlike static-weighting routing, health-weighted routing is assigned by analyzing the health of a given server in the machine pool. Each server in a SharePoint environment has a health score, assigned by the SharePoint Health Analyzer, varying from a score of 0 (healthy) to 10 (unhealthy).
| EXAM TIP |
| the deployment mode can be configured using the -routingWeightScheme switch of the |
| Set-SPrequestManagementSettings cmdlet. |
Machine pools
Machine pools are groupings of routing targets. Requests that match a given routing rule can be routed to a particular grouping of SharePoint web servers (instead of all of them), whereas requests that do not match a rule are routed to any available web server in the farm. Machine pools can be administered using the Get-/Set-SPRoutingMachinePool cmdlet.
Monitoring request management
There are a series of metrics that can be tracked within the Event Viewer to monitor the health of request management (see Table 1-2).
TABLE 1-2 Request management counters
| Counter name | Description |
| Connections Current | The total number of connections that are currently open by Request Manager. |
| Connections Reused / Sec | The number of connections per second that are reused when the same client connection makes another request without closing the connection. |
| Routed Requests / Sec | The number of routed requests per second. The instance determines the application pool and server for which this counter tracks. |
| Throttled Requests / Sec | The number of throttled requests per second. |
| Failed Requests / Sec | The number of failed requests per second. |
| Average Processing Time | The time to process the request that is the time to evaluate all the rules and determine a routing target. |
| Last Ping Latency | The last ping latency (that is, Request Manager’s PING feature) and the instance determine which application pool and machine target. |
| Connection Endpoints Current | The total number of endpoints that are connected for all active connections. |
| Routed Requests Current | The number of unfinished routed requests. The instance determines which application pool and machine target. |
These metrics levels can be monitored in both the event and tracing logs using the SetSPLogLevel PowerShell command. For instance, the following PowerShell command will increase the trace severity levels to verbose:
Set-SPLogLevel "Request Management" -TraceSeverity Verbose
