MS CRM Load Balancing, a simpler option.
I have been struggling with Microsoft’s concept of CRM load balancing and server roles. After reading everything that I could get my hands on it appeared that just installing two or more full CRM installs would be the simplest and most redundant solution in some situations. While doing more research I found this blog entry from Customer Effective’s CEBlog that outlines the solution in a very simple and straight forward way which I have included below.
Can I run two Async Services?
According to the CRM Planning Guide at the botton of page 4-59, Miscrosoft says you can run two asyn services at once on seperate platform servers or full application servers. However, there is an known issue that is corrected in Update Rollup 7 or via this KB975490
___________________________________________________________________
Separate Server Roles and Microsoft Dynamics CRM 4.0
One of the choices when deploying Microsoft Dynamics 4.0 is whether or not to separate server roles.
When you install Dynamics CRM on a server, the application layer (web server, CRM application) and the platform layer (asynchronous service, discovery service, sdk) run on the same server.
There are several reasons that you would want to separate server roles. For example, if you have a heavy quantity of asynchronous activity, such as imports, workflows or plugins, you don’t want to affect availability of the application, and you don’t want asynchronous operations to have a long backlog and slow down the amount of time it takes for new asynchronous operations to be processed.
Traditional Approach
The traditional way to separating server roles with Dynamics CRM 4.0 Enterprise was to select the separate server roles option when installing. This gives you the option to install the roles that you want on a server, so you can have one server be the application role, and have another be the platform role, for example.
Complexity
Before you do this, you should be aware that going with the separate server roles may introduce some complexity into your environment. When everything runs on one server, everything uses the same server URL; however, if the platform role is separated, things that hit the discovery service, such as the outlook client, email router, and custom code will need to hit the URL of the platform server, not the application server URL, and having two different addresses may add some confusion for certain users. If you elect to deploy your environment Internet facing, or IFD, so you have CRM available to people not on your network, there is a lot of complexity and frankly this option is not very well documented in the IFD scenarios documentation.
IFD and Separate Server Roles
if you have separate server roles, you will need to expose both the app server website and the platform server website externally. You will need to run the ifd tool on both the application and the platform server–this is not documented in the ifd scenarios document, but is required if you want external users to be able to configure Outlook clients in ifd mode, You will need to have ssl certificates on both the application and platform server, which will cost you extra. The IFD scenarios document doesn’t say this, but you will have to have your platform server URL be organization specific–if your CRM URL is myorg, for example, you will need the URL to be something like myorg.platform.company.com. again, not documented, but CRM will expect the org name to be in the Url when you configure the Outlook client. Users will have to configure their outlook clients using the platform server URL, not the CRM application URL. The reason for that is the outlook client connects to the discovery service during configuration, and the discovery service is part of the platform role, not the application. having a different CRM URL for outlook client and web client can be very confusing to some users.
An Easier Approach
As we have seen, the traditional approach to separating server roles may add some complexity to your CRM deployment; however, that doesn’t men you shouldn’t do it. Rather, there is another approach that achieves the same goals.
This approach is to install the full CRM application on both servers, both pointed at the same CRM databases. On server A, stop the asynchronous service, and on server B, start the asynchronous service. Drive all of your users to the URL of server A.
The end result is that, like with separate server roles, you have all application traffic handled by server A, and all asynchronous load handled by server B, but you avoid all of the complexity of traditional separate server roles. Users will be able to use the same URL for the web and outlook interfaces, and Internet facing deployment will be much more straightforward, requiring only on URL or ssl cert.
This is the approach that we recommend—it will make your life much easier.
Thanks To Alex Fagundes at Power Objects for providing input for this post.
Sourced From: CEBlog
