The load balancing service has a range of configuration options to optimise the service for your particular requirements. Our support team will be happy to help with any requests for changes in configuration options that are shown below.
Here are some questions for your consideration when choosing the Performance Patrol Load Balancing Service.
Which ports/services will need to be load balanced? Typically this will be, but is not limited to, ports 80/443 for load balancing on an HTTP/HTTPS website.
Does your application store session information in a database or do you require persistance (sometimes referred to as "sticky sessions")? If you require persistence, how long should this be set to? In other words, how long before a customer's session can be redirected to different server? By default persistence is disabled.
By default the load balancer will check the real server is responding on the port that requests are being directed to. It is also possible to configure the load balancer to check a URL for a text string to indicate that the service is responding normally. If you would like us to set this up please provide:
By default our load balancer's service check is set to 5 seconds, but we can change this value according to your needs. Altering this may affect the speed of failover should a server become unavailable.
There are a few different ways to schedule requests to your front end web servers, these include:
Robin Robin: distributes jobs equally amongst the available real servers.
Weighted Round Robin: assigns jobs to real servers proportionally according to the real servers' weight. Servers with higher weights receive new jobs first and get more jobs than servers with lower weights. Servers with equal weights get an equal distribution of new jobs.
Least-Connection: assigns more jobs to real servers with fewer active jobs.
Weighted Least-Connection: assigns more jobs to servers with fewer jobs and relative to the real servers' weight . This is the default.
Locality-Based Least-Connection: assigns jobs destined for the same IP address to the same server if the server is available and not overloaded; otherwise assigns jobs to servers with fewer jobs, and keeps it for future assignment.
Locality-Based Least-Connection with Replication: assigns jobs destined for the same IP address to the least-connection node in the server set for the IP address. If all the nodes in the server set are over loaded, it picks up a node with fewer jobs in the cluster and adds it into the server set for the target. If the server set has not been modified for the specified time, the most loaded node is removed from the server set, in order to avoid a high degree of replication.
Destination Hashing: assigns jobs to servers through looking up a statically assigned hash table by their destination IP addresses.
Source Hashing: assigns jobs to servers through looking up a statically assigned hash table by their source IP addresses.
Shortest Expected Delay: assigns an incoming job to the server with the shortest expected delay.
Never Queue: assigns an incoming job to an idle server if there is one, instead of waiting for a fast one; if all the servers are busy, it adopts the Shortest Expected Delay policy to assign the job.
Once configured, the status of the load balanced cluster will be available through your Memset account at:
https://www.memset.com/control/
The load balanced IP address will be allocated to one of your servers for bandwidth accounting purposes. Remember that the bandwidth for the load balancer will show up under this server, and that any bandwidth changes to the load balancer will need to be made on the server this load balanced IP address is administratively assigned to.
If you have any questions about this service please drop a support ticket to support@memset.com and we will be happy to advise further.
Last updated 2 September 2015, 16:01 GMT