Load and performance testing web applications will allow you to determine whether or not your deployment will require a clustered environment. When the test results show that the current throughput is restricted by the capacity of the server but target workloads are not yet met, this is a situation where you can achieve higher scalability by implementing clusters to your environment. Clustering achieves higher scalability by introducing more servers or nodes to expand the capacity of the environment. Obviously, the benefits of adding hardware include higher capacity, reliability, availability, and scalability. But also consider that clustering also adds complexity to your deployment by requiring added maintenance and an increased need for deployment/upgrade automation. To ensure quality of the environment you must always validate your clustered environment and prove out the increased scalability. Use a methodical performance testing approach. Don’t try to extrapolate! It’s not as easy as “3 nodes in a cluster will support 3x the workload.”
An efficiently tuned deployment will, in turn, display an efficient use of server resources (memory, CPU, i/o, etc). Using a cluster increases the number of servers and distributes the workload amongst several servers. This even distribution of the workload can dramatically increase scalability. Not only can this improve the end user experience by reaching higher workloads with predictable response times but it can increase the reliability and stability of the deployment. The cluster acts as a single server so the loss or shutdown of any of the nodes in the cluster will not result in loss of sessions or application data. In the end, the user experience is less frequently interrupted and isn’t affected by a single maxed out server or a loss of a server.
When performance or load testing your application uncovers a clear need to introduce clusters or farms to support the target workload, you will want to take into account the following considerations: First you should configure the cluster efficiently for internal maintenance such as data synchronization and heartbeat communications. User sessions which live in memory are more quickly failed over to another node in the cluster instead of persisting them to the database. However, writing the sessions to disk is more permanent which may have its own advantages. Make sure you have tested the performance prices for data synchronization and heartbeat communications. The goal is to configure the cluster to increase scalability with as little overhead as possible.
Load balancers are generally placed out in front of the clusters. These load balancers can be a software solution or a hardware solution. Their job is to distribute the load evenly to the nodes in the cluster. Just as important, LB’s reroute traffic when one node of the cluster goes down. This allows for the “transparency” of several servers acting as one. There are several more mature algorithms for distribution than traditional “round robins.” Smarter LB’s takes into account the CPU and resource usage and overall load of each server and their job is to direct the request to the least loaded server. The number of active users doesn’t always equate to more resources being actively used, rather it depends on the types of transactions being executed – lightweight vs. expensive transactions. Smart LB’s will detect workload and direct incoming traffic based on resource usage. Often LB’s will use sticky sessions based on the client’s cookie and/or IP address to route subsequent requests to the same node of cluster where the user session lives. When load testing these types of environments, it’s a requirement to have a load tool which supports IP Spoofing. This is used to generate the load of many virtual users using multiple IP addresses all from a single machine. Otherwise, the total load would go to a single cluster node.
Types of Clustering
Clustering can be achieved using a few common techniques. Vertical clustering adds capacity to the deployment by installing multiple nodes of a cluster on a single machine. With this approach you must take into consideration the physical limitations of that machine (CPU, memory, i/o) and be careful not over utilize resources; otherwise adding more nodes becomes pointless due to saturation. Horizontal clusters refer to deploying more physical machines. With this approach, each physical machine can run one or more of the nodes of the cluster. Cloud bursting is a way of having a node both within the LAN and a node in the Cloud to be turned “on” during high volume usage or be strategically placed in different geographical locations. The appropriate technique really depends on the specifics of your environment. If you need more capacity and you have beefy infrastructure servers but do not have enough web servers or app servers to fully utilize the underlying hardware, choose the vertical clustering approach by adding more nodes to the same machine. On the other hand, if more physical resources are needed to handle the workload, then build out a horizontal cluster by adding more hardware and deploying more nodes.
How to Load Test a Cluster?
It’s important to take a methodical approach to load testing a clustered environment. Load patterns such as ramping tests allow you to identify the current capacity as well as increased scalability as you add more nodes to the cluster. Remember that doubling the number of nodes in a cluster does not equate to doubling its capacity. Many components impact its performance gain such as the communications between the nodes used to just make the cluster work properly. The resource cost increases dramatically with the number of nodes. Capacity is relative and is dependent on myriad other components within the infrastructure. For example, adding another node to the cluster may give the application layer 2x the throughput (although this is not really possible due to “housekeeping” from internal administration overhead to maintain that cluster), but let’s say the single webserver out front is already using all its worker threads, then requests will be queued while waiting for a thread to become available and overall throughput will not increase. Only through the analysis of load test results will you completely understand the increased scalability effects of a cluster. Consider another scenario: You have identified a need for building out a cluster of application servers, however you deploy too many nodes resulting in a backlog of requests on the shared database. Performance and load testing will uncover this vulnerability and many other potential scenarios that could otherwise go undetected. Having a comparison analysis feature built right into the load tool will allow you to run tests back to back, after turning on/off nodes in the cluster, and quickly visualize the differences. Also, having the tool with a built-in cloud load generation feature will save time and money setting up and maintaining the performance architecture environment, especially for high load tests.
The Right Approach?
Adding clustering to a deployment allows a web application to achieve higher workloads and gives the advantage of higher availability. However, you must conduct performance tests in order to build out an efficient cluster which meets your goals. Don’t forget to weigh the benefits vs. added maintenance complexity/cost. Clusters require a high level of expertise to implement and maintain so they aren’t the best solution in every situation. Make sure all moving parts are documented and insist on a complete architectural diagram for future systems administrators (diagrams to include hierarchical transaction pathways as well as location of each node in the cluster including the admin consoles). In the end it’s all about delivering the best possible end user experience and in many cases clustering is an excellent solution for increasing scalability of your web deployments.