Clearing the myths between Request Management service in SharePoint 2013 and Network Load balancer:

Alright. So the heading of this article would have pretty much given a brief explanation about what this post would 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 so that anybody would possibly get confused. So in this post I’ll be explaining what these two mean in detail 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 on what “Request Management service” is all about and how it works. However, to put it in simple words….Request Management service take 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 about that in detail. As always Spencer has did a fabulous job in explaining it on detail.

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.

  1. Request manager is the first code that runs in response to HTTP requests. It is implemented in SPRequestModule
  2. 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.

1.png

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 you WFEs go down you can let APP server handle user web requests temporarily.

2.png

Now let’s discuss on 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 gets 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 need 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 then 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:

3.jpgIntegrated Mode:

4.jpg

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 exist. The second one is called the (Integrated mode) where you will find the RM service being turned 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 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 these are optimal for any successful SharePoint implementation.

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

 

Advertisements

2 thoughts on “Clearing the myths between Request Management service in SharePoint 2013 and Network Load balancer:

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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