Load balancing can feel like an abstract concept in Guardium. In this article, I want to break down both Enterprise Load Balancing (ELB) and Internal Load Balancing (ILB) and explain them in a simple, practical way. Together, they help keep monitoring traffic flowing smoothly, even when workloads spike. I will walk through how they work individually, how they work together, and what's new in ILB in GDP 12.2+ that makes upgrading even more worthwhile for users aiming to improve performance and resilience.
1. Enterprise Load Balancing (ELB)
The Central Manager that assigns S‑TAPs to the right collectors
ELB does dynamic load balancing on the Guardium Central Manager. Each collector periodically reports their metrics such as: CPU, memory, inspection engines load, number of STAP collections etc. to the CM. CM builds a real-time load map showing how busy each collector is, then dynamically assigns S-TAPs to the most suitable collector(s).
ELB Architecture
Quick Examples:
Example 1: S-TAP restart
Example 2: Dynamic rebalancing
· When Collector A gets busy → ELB can move some S-TAPs to Collector C automatically.
Example 3: Failover
· If Collector B goes down → CM instantly redirects affected S-TAPs to Collector A or C.
Simply put -- ELB handles the big picture: balancing assignments, relocating S‑TAPs when collectors get overloaded, and managing failover if a collector goes down.
Refer to this documentation on how to enable ELB on your GDP environment.
2. Internal Load Balancing (ILB)
The real‑time balancing engine built into the S‑TAP ↔ sniffer connection
Now, ILB is all about instant, moment‑to‑moment balancing. When ILB is enabled, each S‑TAP keeps a live, bi‑directional communication with every sniffer it is connected to – whether those sniffers are on Collectors or Edge Gateways. Through this, sniffers continuously send back capacity information — how busy they are right now and how many more sessions they can safely take. This helps the S‑TAP react immediately to do load balancing instead of waiting for ELB’s periodic reassignment.
Side note – Have you heard of Edge Gateway? (new to GDP 12.2.1)
In the modern Guardium architecture, Edge Gateway is a Kubernetes-based solution that collects data from Linux/Unix S-TAPs and Universal Connectors 2.0 starting in GDP 12.2.1. (Soon Edge Gateways will support Windows STAPs). When using Edge Gateway, S-TAPs or Kafka-based Universal Connectors send traffic to Edge Gateway instead of directly to collector appliances. ILB works the same way here — S-TAPs communicate with Edge Gateway sniffers to balance traffic in real time.
How ILB works
Sniffers continuously sends these signals to the S-TAPs:
- memory usage
- queue depth
- open session count
- traffic rate... etc.
Then STAP dynamically sends traffic to the most available sniffer.
Quick example
Imagine that two collectors (A and B) are available to an S‑TAP.
No manual intervention. No lost traffic.
New in GDP 12.2+, ILB can also support partial failover – moving traffic in the middle of a session to another sniffer. It used to be that the whole (new) session is moved or nothing. Now session state is preserved during a failover. So if S-TAP has a long session, we can still move traffic in the middle of a session to a new sniffer when the first one gets overloaded.
Refer to this documentation page on how to enable ILB on your S-TAPs.
3. How ELB and ILB Work Together
ELB and ILB are designed to be complementary.
- ELB: Decides which collectors an S‑TAP is allowed to use.
- ILB: Decides, moment by moment, how to distribute traffic among those sniffers (on Collectors or Edge Gateways).
A practical example
Step 1 — ELB sets the pool
Step 2 — ILB distributes in real time
Step 3 — ILB requests expansion
This combination prevents overloads and ensures smooth traffic flow, even during sudden spikes.
4. Why This Matters for 12.2 Upgrades
These load balancing features were here before GDP 12.2. But enhanced ILB in GDP 12.2+ works even better with mid-session failover capability. When you enable ILB and ELB together, you get a system that's far more responsive and easier to operate:
- Real-Time Traffic Management: ILB responds in seconds, shifting traffic as soon as collector shows signs of stress.
- Effortless Spike Handling: Whether it's nightly ETL, backups, and reporting workload bursts, ILB rebalances automatically.
- Performance stays predictable: ILB proactively keeps collectors from overloading.
- Lower Operational Overhead: Your team can focus on strategic initiatives while the system manages itself.
Guardium Best Practices
- Turn ILB on when you have 2+ collectors in a pool.
- Keep policies/inspection engines consistent across the ELB pool. (There is a parameter to allow policy mismatch, but standardizing avoids surprises.)
- For External S‑TAP in Kubernetes: Kubernetes load balancers help scale E‑STAP itself; ILB/ELB handles collector distribution.
- For Edge Gateway deployments: ILB provides the same real-time load balancing benefits with S-TAPs communicating with Edge Gateway "mini-snif" (that's what we call sniffer pods on EG).
I didn’t cover other load‑balancing options here — like external load balancers, Kubernetes service load balancing for External S‑TAP, or Kafka’s built‑in load balancing for Universal Connector deployments. But hopefully this walkthrough of GDP native ELB and ILB gives you a clearer picture how GDP quietly does most of the heavy lifting of load balancing.