Microsoft Dynamics is a critical ERP and CRM tool, used every day by businesses all over the world. The application therefore needs to be highly available and scalable. Here's how you can achieve that.
Microsoft Dynamics history time!
Microsoft Dynamics has been around since the late 90's in the ERP and CRM space, and has been owned by several big names (IBM, Damgaard Data, Navision) until Microsoft acquired it in 2000.
It is used in various industries such as retail, services, manufacturing, financial services, and the public sector. Since its initial release it has evolved multiple times with new modules being added to the suite of applications, and has been renamed several times. Currently it can be easily integrated with other Microsoft tools or services that are essential to the business.
Say no more! How can I load balance it?
The short story:- Microsoft Dynamics CRM needs to be deployed in a multi-tenant type of deployment on Microsoft Server 2016, while the load balancing solution HAProxy needs to be deployed on CentOS 7.
Deploying Microsoft Dynamics on Windows Server
I won't go into the ins-and-outs of how to install Microsoft Dynamics - I will leave it to Microsoft's ever-so-extensive library on this:
HAProxy deployment and configuration
For deployment instructions and configuration for HAProxy check out this blog.
Now that HAProxy has been successfully installed, here is the configuration file /etc/haproxy/haproxy.cfg that will be used to load balance Microsoft Dynamics.
global
daemon
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
stats socket /var/lib/haproxy/stats
defaults
mode http
log global
option tcplog
option dontlognull
retries 3
maxconn 10000
option redispatch
timeout connect 5s
timeout client 8h
timeout server 8h
listen stats
bind *:8080
mode http
option forwardfor
option httpclose
stats enable
stats show-legends
stats refresh 5s
stats uri /stats
stats realm Haproxy\ Statistics
stats auth loadbalancer:loadbalancer
stats admin if TRUE
listen DynamicsClusterForceToHTTPS
mode http
acl force src 192.168.77.10 192.168.77.100
reqadd X-Forwarded-Proto:\ https if force
redirect scheme https code 301 if !force
listen DynamicsCluster
bind 192.168.1.100:443
mode tcp
option tcplog
balance leastconn
stick on src
stick-table type ip size 10240k expire 8h
option tcp-check
tcp-check connect 443
server win2016-dynamics-rip1 192.168.1.200 inter 10s rise 2 fall 3
server win2016-dynamics-rip2 192.168.1.201 inter 10s rise 2 fall 3
To ensure that a client will not end the session prematurely, the connection will time out between the client and the frontend in 8 hours client timeout 8h and from frontend to backend in 8 hours server timeout 8h. This could be considered a bit of an over estimation, however I have encountered deployments that had this requirement.
The HTTP traffic will be forced to HTTPS using DynamicsClusterForceToHTTPS to the frontend DynamicsCluster . Source IP persistence (session stickiness) stick on src will ensure the clients stickiness to one of the backends and the entry will be stored in persistence table for 8 hours stick-table type ip size 10240k expire 8h, essentially for the duration of a work day.
The connections will be distributed between the two applications servers using the Least Weighted Connections load balancing algorithm balance leastconn, the real server with the least connections will be prioritized for new connections.
For the configuration above, HAProxy does SSL bridging (or SSL passthrough), thus the SSL connection is stripped on application servers. Of course the configuration can be expanded and we can speed up the application servers by taking some workload off them i.e. terminating the SSL connection on the load balancer.
And there you have it. For further details on how to accomplish this, check out our Client Certificate Authentication with HAProxy blog.