Blog Viewer

When performing DAM – Database Activity Monitoring – the legacy deployment is to install the agent on the DB server, register the agent and assign it to a specific gateway. There is also an option to assign a secondary gateway for fail-over purposes.

This model worked well for years, but as audit requirements changed so did the need to monitor database activity. There are customer deployments that have over 100 agents deployed and actively monitoring. The legacy deployment was simply not sufficient to support large agent deployments. There needed to be more flexibility and visibility.

DAM Clusters were introduced just for that reason. A cluster allows multiple gatways to work together and support a large number of agents. During the agent registration process, the agent is assigned to the cluster manager and the manager will decide which gateway in the cluster will be assigned the agent. This is done based on information sent by the gateways in the cluster, which results in a value that equates to the current load being seen by that gateway. The manager uses this load information to determine the most suitable gateway and assigns the new agent to that gateway. Clusters also allow the Imperva Administrators to manually move agents between gateways, providing an extra layer of control.  

Clusters use a redundant gateway which is a standby gateway that will take over for any failed gateway in the cluster. This is an automatic process that occurs, providing a dynamic process which allows auditing to continue, even when there is a failure within the cluster. 

The UI on the MX provides a full view of the Cluster and the health of each gateway in the cluster. Its also from here that you can manually manage the agents if so desired.

Clusters are very scalable, and are designed to handle the load today's DAM deployments generate, while providing flexible management and dynamic redundancy.