12 Reasons Why You Should Use The Log Insight Integrated Load Balancer

I have already talked about the differences between the ILB and an ELB, but I have heard requests for specific reasons why the ILB should be used. How about I give you 12.

1. Simple configuration: Select the enable checkbox (from /admin/cluster — requires you have more than one node), enter the VIP, select save. That’s it, no domain expertise required! Try to configure an ELB that quickly.
2. Central management: No third-party products. No need to deal with another team within the organization or manage multiple different products.
3. TCP + UDP load balancing: Not all load balancers support UDP load balancing, the ILB does!
4. L4 + L7 load balancing: Load balancers are really good at balancing web traffic, but they are not known for balancing syslog traffic. The ILB balances syslog traffic with ease. L7 load balancing, sometimes called message-based load balancing (MBLB), is hard, but LI makes it easy! The result is a near perfect balance of ingestion across all nodes in the cluster. Many ELBs do not support MBLB. Most of those that do are hard to configure especially for syslog traffic.
5. Dynamic configuration: Need to add or remove a node? No problem! The ILB is aware of cluster changes and handles them automatically. While you can define pools on an ELB, you have to ensure all new nodes are deployed in that pool for automatic configuration to work. Have a node that is overloading or experiencing issues? No problem! The ILB checks the health of nodes in the cluster and compensates for unresponsive or overloaded nodes. While ELBs support health checks, performing health checks on syslog traffic is challenging.
6. HA: If the node hosting the VIP goes down, the VIP will automatically failover to another node in the cluster. HA is enabled by default, no additional configuration needed!
7. Cost efficient: The ILB runs on the existing LI resources you have already provisioned. No additional resources are required. No additional licensing is required. No additional cost is required!
8. End-to-end support: VMware already supports Log Insight and now it supports the ILB as well. This gives you complete, end-to-end support assuming you are running the Log Insight agent and/or forwarder. Again, no additional cost!
9. Correct source: The source field of events is based on the last device to send an event. In the case of an ELB this would be the ELB (unless you really know what you are doing), with the ILB it is the actual last device.
10. Source of alert links: If an alert is sent from a LI node and the LI node is part of a cluster with the ILB configured then the link back to LI will be to the ILB instead of the individual node. This is beneficial for a variety of reasons including from a security perspective as you should only allow access for ingestion and query to the ILB instead of to individual nodes. There is no way to change this when using the ELB.
11. Target for vSphere integration: With the ILB configured, vSphere integration will default to the ILB. Using the ILB provides ingestion HA for vSphere events. With an ELB you would need to configure this manually.
12. Based on OSS: The ILB runs LVS behind the scenes. No, VMware did not write another load balancer technology. Yes, this load balancing technology has been heavily tested and is fully supported by the OSS community and VMware. The ILB is highly performant, highly scalable and the solution for load balancing of Log Insight cluster traffic.

© 2015, Steve Flanders. All rights reserved.