4.3 Cluster Load Balancing

vRealize Log Insight requires a load balancing method when configured as a cluster. Prior to the release of vRealize Log Insight 2.5, the only option for load balancing syslog traffic across the clusters nodes was to use of an external load balancer. vRealize Log Insight 2.5 introduced an integrated load balancer feature that supported Layer 4 and Layer 7 load balancing, in addition to automated failover of the Virtual IP Address (VIP), thus providing good feature parity with external load balancers. The integrated load balancer also helps to simplify the vRealize Log Insight environment and reduces the configuration complexity associated with external load balancers, which in turn can help lower operational costs. The integrated load balancer also provides the following functionality:

Detailed configuration for external load balancing syslog message traffic across vRealize Log Insight nodes will vary from device to device and is beyond the scope of this document. The following is an overview of the principles and design considerations required from an architectural perspective:

• If UDP transport is used, a load balancer that supports UDP traffic is required. These are not as common as you might think, and could provide a reason for you to elect to send syslog messages using TCP.

• Your choice of load balancing algorithms depends on the choice of hardware or software appliances employed. To avoid issues caused by an unbalanced cluster node, use the Least Connections algorithm, if available.

• Verify that the throughput of the load balancer meets the needs of the planned environment. Some load balancing devices are licensed, based on the maximum MB per second throughput allowed, or on the maximum number of concurrent connections. Verify that the device choice can handle the number of anticipated connections and the required throughput, as well as allow for future growth.

• Avoid allowing “long-lived” TCP sessions in the load balancer configuration. The aim of this recommendation is to keep the load balancer from maintaining open sessions with the target server and to avoid unbalanced cluster nodes, if there is a prolonged outage between the syslog client and syslog server.

As with any design decision, whether to opt for the integrated load balancer, or an external load balancer, will come down to the specific customer use cases and requirements, and any other key design factors. When evaluating the load balancing options, consider the following key points:

• The integrated load balancer service runs on the existing vRealize Log Insight nodes and is simple to configure with only an additional IP address required. There is no additional cost or operational support required.

• The integrated load balancer supports all vRealize Log Insight ingestion protocols, including Layer 4 and 7 load balancing, with no additional configuration required.

• While only a single VIP can be configured with the integrated solution, and all nodes must be on the same Layer 2 network segment, the native load balancer configuration is capable of supporting the maximum ingestion load of the vRealize Log Insight cluster.

• External load balancers, while capable of performing multiple load balancing tasks, are typically managed by a different operational team, which might introduce delays in configuration and operational support.

If you elect to use an external load balancer for the design, you can choose from a range of physical or virtual devices, however, VMware does not provide any specific recommendation. The following list includes some vendor technologies that can provide the required load balancing services:

If you are looking for a free open source solution for a proof-of-concept or lab environment, look at HAproxy/NGINX at http://www.haproxy.org/. If you require UDP load balancing, you can look at the Zen Load Balancer at http://www.zenloadbalancer.com/community/downloads/.