Windows: S-TAP load balancing models and configuration guidelines

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

Failover

S-TAP sends traffic to one collector (primary) and fails over to the secondary 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, 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, the primary host becomes available again, or until the S-TAP is restarted (at which point it attempts to connect to its primary host first). If the secondary host system becomes unavailable, it fails over to another secondary if there is one defined. In the second case S-TAP fails over from the secondary Guardium® host back to the Primary Guardium host.

Set up a primary and up to two secondary collectors. You can either define one collector as a standby failover collector only, or a few failover collectors. When you use one standby failover, one collector is usually sufficient for 4-5 collectors. When you use 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. If the primary becomes available, the S-TAP fails back from the secondary Guardium host back to the Primary Guardium host.

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

  1. In the Details section of the S-TAP Control window, set the value of the Load balancing parameter to 0; In the Guardium Hosts section: add at least one secondary Guardium Host.
    Note: If you are not an advanced user, do not update the default failover configuration default values.
  2. Before designating a Guardium system as a secondary host for an S-TAP, verify these items.
    • The Guardium system must have connectivity to the database server where S-TAP is installed. When multiple Guardium systems are used, they are often attached to disjointed branches of the network.
    • The Guardium system must not have a security policy that will ignore session data from the database server where S-TAP is installed. In many cases, a Guardium security policy is built to focus on a narrow subset of the observable database traffic, ignoring all other sessions. Either make sure that the secondary host will not ignore session data from S-TAP or modify the security policy on the Guardium system as necessary.

    Enhanced failover mechanism to avoid data loss

    12.1 and later

    The main goal of failover mechanism is to preserve the session parameters when switching the S-TAP to the secondary collector. The regular failover mechanism saves session parameters in the form of failover messages that are received from the primary collector over the network. If a failover occurs, the mechanism forwards the failover messages to the secondary collector. In rare cases, the failover messages are lost. To address this, the enhanced failover mechanism, also saves session parameters in the form of several raw database protocol packets. If a failover is required and the failover messages are lost, the failover mechanism forwards the raw database packets to the secondary collector.

Load Balancing

This configuration balances traffic from one database onto multiple collectors. This option is useful when you must monitor all traffic (comprehensive monitoring) of an active database. (Note that for outliers detection, the collectors must 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, use this method because it performs session-based load balancing across multiple collectors. An S-TAP can be configured in this manner with up to 10 collectors.

Complete the following configuration procedure in the Details section of the S-TAP Control window:
  • Set the value of the Load balancing parameter to 1 for balancing the load.

Internal load balancing

12.1 and later

The Internal Load Balancer (ILB) helps avoid data loss caused due to collector overload.

The ILB evaluates the data load and helps avoid the data loss by proactively forecasting the load on the collector and redirecting the traffic to another collector to balance this load.

On the sniffer, ILB dynamically determines the number of sessions that a sniffer can accept from the S-TAP. This value is based on the collector's capacity for session information and processing collector load.

ILB sends two values to the S-TAP: the total number of allowed sessions on the appliance and the total number of sessions currently opened in the sniffer.
Note: The calculation of current sessions includes all the connected S-TAPs.

Each S-TAP keeps count of open sessions and uses the allowed session count to determine whether it can send new session data to the existing collector.

If number of open sessions is more than the allowed session count, then the S-TAP redirects new sessions to another collector.

If the number of open sessions do not exceed the allowed session count then the S-TAP may send the new sessions to existing collector.

Enabling internal load balancer

12.1 and later
Enabling on Windows
  1. To enable the internal load balancer feature on S-TAP, set the INTERNAL_LOAD_BALANCER_ENABLED parameter to 1 . Default value = 0. Value range = 0, 1.
  2. Also, set the PARTICIPATE_IN_LOAD_BALANCING to 1 for Windows.

    Default value = 0. Valid values = 0 - 3.

Enabling on Collector
  1. Create a session-level policy. For more information on creating session-level policy, see Creating session-level policies.
  2. In the Rule action field, select CONFIGURE.
  3. In the Option field, select ILB and click OK.

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.

The persistence of S-TAP is configured by the failover parameters:
  • TAP_MIN_TIME_BEFOREFAILOVER: The time interval, in minutes, after which the S-TAP switches to secondary Guardium system if: it cannot connect to its primary Guardium system; it can connect to its primary Guardium system but cannot write to its buffer. Default is 5.
  • TAP_MIN_HEARTBEAT_INTERVAL: Maximum time the S-TAP attempts to write to the primary Guardium system buffer before attempting to write to the secondary Guardium buffer. Default is 30 sec, meaning it tries to write at least 5*60/30 times before failover.

S-TAPs in the F5 environment upload their log files and results of running diagnostics (all files from ..\Logs folder except for memory dumps) to the active collector and central manager (if exists) to the location ./var/IBM/Guardium/log/stap_diagnostic/

  1. In the Details section of the S-TAP Control window, set the value of the Load balancing parameter to 3 for the grid model.

  2. All can control = 1.
  3. Guardium Host = <the IP of the Virtual IP of the balancer, to which all S-TAP database clients point to>.

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.

In the Details section of the S-TAP Control window, set the Value of the Load balancing parameter to 2 for redundancy. For more information, see S-TAP Control: Details.