Clearing The Myths Between Request Management Service In SharePoint 2013 And Network Load Balancer

Alright. So, the heading of this article will have pretty much given a brief explanation of what this post will be about and hence, I’m not going to write a brief introduction session here about this post.

I’m pretty sure that a lot of SharePoint Geeks out there have written a lot about Request Management service in SharePoint 2013 and Load balancer configuration for a SharePoint 2013 farm. However, there seems to be a lot of confusion among SharePoint practitioners in understanding the difference between these two. I didn’t mean to offend anybody here but the features and functionalities of these two are so similar that anybody would possibly get confused. So, in this post, I’ll be explaining what these two mean, in details, and how they differ from each other (meaning where the boundary for Request Management service stops when compared to a load balancer).

Now, let’s get into the meats and potatoes ….

1. Request Management Service in SharePoint 2013
   
   For those who are new to SharePoint 2013 or if you’re hearing about “Request Management service” for the first time, please go ahead and take a look at my blog post on Request Management service. I’ve given a detailed explanation of what “Request Management service” is all about and how it works. However, to put it in simple words- Request Management service takes care of managing incoming requests by evaluating the logic rules set against them in order to determine which action to take, and which machine or machines in the farm (if any) should handle the incoming requests. Now, there’s a lot of mechanism which happens in RM service. Please take a look on Spencer Harber’s article on Request Management service to know in detail. As always, Spencer has done a fabulous job in explaining it.
   
   In addition to this, there are couple of other important points that one should be aware of as far as Request Management service is concerned. 
   
   
• Request Manager is the first code that runs in response to the HTTP requests. It is implemented in SPRequestModule.
• Request Manager requires the SharePoint foundation web application service to be started on the server.
• Request Manager service should only be started on a server that’s acting as a WFE, else it’s of no use.
  
  
  
  
2. Load balancer for SharePoint
   
   Now, as you’re aware, high availability in SharePoint is achieved in the web tier level by deploying multiple front-end servers to serve web pages and host web parts. A load balancer directs traffic across these servers, monitors health, and ensures that the best possible target is used for individual requests. The default SharePoint architecture works in such a manner that any server in the farm which has the “SharePoint foundation web application service" turned on will be acting as a Web Front end server. Hence you can go ahead and turn off this service on a server that is acting as an App server. However, if your servers have enough resources, then there shouldn’t be any harm on leaving it on, as in case if your WFEs go down, you can let APP server handle user web requests temporarily.
   
   
   
   Now, let’s discuss how they differ from each other, so that we don’t get confused by their similar functionalities:
   
   The first thing which we need to understand is that the Request Management service becomes effective only when the user request gets passed the Network Load balancer which takes care of handling user traffic . As you’re aware, the NLB is the one which takes care of handling user traffic and if a user’s request doesn’t even get passed the load balancer, then technically it means that the user’s request is not hitting the SharePoint farm where the Request management service is configured .To put it in simple words, the user’s request needs to pass the 1st gate which is the NLB and only upon the successful completion of that, the user’s request will hit the appropriate Web front servers where the Request Management service will be configured . So, once the user’s request hits the SharePoint farm, the RM service will validate the request and will then act accordingly. I believe the image below will give you a clear understanding of how this is configured for a SharePoint 2013 farm.

Dedicated mode


Integrated Mode


In both the modes, you can notice that the user traffic first has to go through the HLB, before it reaches the SharePoint 2013 farm where the Request Management service is configured. Now, if you’re more curious in understanding the difference between the above said two modes … In the first mode (i.e. Dedicated mode) you will have a SharePoint farm configured only for Request Management service (meaning all the servers in that farm will have only the RM service turned on the WFE’s). In this mode, the SharePoint farm which has the RM service configured will be configured in such a way that it’s kept between the LB and the actual PROD server where the user’s content exists. The second one is called the Integrated mode where you will find the RM service being turned on on all the WFE servers in the SharePoint farm. The first mode is pretty expensive bearing in mind the license costs and will be mostly used in very large SharePoint farm implementations .The second mode is pretty affordable because in this mode, all the WFE servers which are part of the actual farm will have the RM service turned on in it.

To conclude RM service and NLB/HLB are two different things altogether and they don’t suffice for  the same purpose .The NLB/HLB takes care of sending the user request to the appropriate WFE’s whereas the Request management service takes care of how to handle that incoming request which is sent to the WFE server. Both of these are optimal for any successful SharePoint implementation.

Thanks for reading this post …..Happy SharePointing!!