Linux and UNIX systems: S-TAP Load Balancing models and configuration guidelines

Understand the S-TAP load balancing models, and choose the one appropriate to your setup

Each load balancing model is described here, along with its specific parameter requirements.

Failover

S-TAP sends traffic to one collector (primary) and fails over to one or more collectors (secondary, thirdly, and so on) as needed. The S-TAP agents are configured with a primary and at least one secondary collector IP. If the S-TAP agent cannot send the traffic to the primary collector for various reasons, the S-TAP agent automatically fails over to the secondary. It continues to send data to the secondary host until either the secondary host system becomes unavailable, or the primary host becomes available again. In the first case, it fails over to the tertiary if there is one defined. In the second case S-TAP fails over from the secondary Guardium host back to the Primary Guardium host. You can configure as many failover collectors as you want, although there is no reason to define more than 3. You can either define one collector as a standby failover collector only, or a few failover collectors. When using one standby failover, one collector is usually sufficient for 4-5 collectors. When using a few failover collectors, each one should run at a maximum 50% capacity, so that there are always resources for additional load. Choose the setup that works best with your architecture, database, and data center layout.

The S-TAP restarts each time configuration changes are applied from the active host.

In the S-TAP Control window, Details section: set Load Balancing to 0; In the Guardium Hosts section: add at least one secondary sqlguard_ip.

Additional failover configuration should be left at the default values, except by advanced users.

Load balancing

This configuration balances traffic from one database onto multiple collectors. This option might be good when you must monitor all traffic (comprehensive monitoring) of an active database. (Note that for outliers detection, the collectors need to be under the same aggregator and central manager in order for the aggregator to process all related data.) When the generated traffic is large and you need to house the data online on a collector for an extended period, this method might be your best choice because it performs session-based load balancing across multiple collectors. An S-TAP can be configured in this manner with up to 10 collectors.

Set participate_in_load_balancing to 1 for load balancing.

Grid

With Grid, the S-TAP communicates to the collector through a load balancer, such as f5 and Cisco. The S-TAP agent is configured to send traffic to the load balancer. The load balancer forwards the S-TAP traffic to one of the collectors in the pool of collectors. You also can configure failover between load balancers for continuous monitoring if the load balancer should fail.

Set participate_in_load_balancing to 3 for the grid model.

Redundancy

In redundancy, the S-TAP communicates its entire payload to multiple collectors. The S-TAP is configured with more than one collector (often only two) and communicates the identical content to both. This option provides full redundancy of the same logged data across multiple collectors. It can also be used for logging data and alert on activity at different levels of granularity.

Set participate_in_load_balancing to 2 for redundancy.

Multiple K-TAP buffers

This mode utilizes extra threads and K-TAP buffers to increase throughput. Set participate_in_load_balancing to 4. See Linux and UNIX systems: Increasing S-TAP throughput