Load balancing

Bravura Security Fabric has a fundamentally multi-master architecture. That means that two or more application nodes are typically active at any one time, able to service user requests, execute unattended processes, and so on.

To distribute incoming workload to multiple servers, either a TCP/IP based load balancer or a DNS round-robin scheme can be used.

Once a user’s web browser is connected to a given Bravura Security Fabric application node, the session should be bound to that server via a "sticky sessions" mechanism. This is because session-specific data is not replicated, for performance reasons. A user can initiate a new session on a new application node (if a different one is available in the same geographic region) but should complete an already-initiated session on the node where that session started.

If using a TCP/IP based load balancer, sticky sessions are a required configuration item.

If using DNS round-robin, sticky sessions can be implemented by having users’ login sessions redirected from a common virtual directory (shared by all Bravura Security Fabric servers) to a server-specific URL. That is:

In addition to load balancing incoming workload, with Bravura Privilege it is possible to associate each application node with geographically nearby managed systems. This is done by setting the "Managed by" application node on each managed system policy.

In the event of a permanent hardware failure on a single node, it may be necessary to reassign the node affinity of managed system policies. See Modes of Failure .

Also, for both Bravura Identity and Bravura Privilege , each system has its own instance of the workflow manager service. Requests submitted to a given workflow manager are processed by the same workflow manager throughout their life cycle. For example, a request to provision a user on application node A will lead to the workflow manager service on application node A to send email invitations to authorizers, to invite implementers to complete tasks, and so on.

In the event of a permanent hardware failure on a single node, it may be necessary to reassign the node affinity of in-flight workflow requests.

Finally, auto-discovery is the responsibility of a single node, which is designated the primary. Responsibility for running the nightly auto-discovery process is the main distinguishing characteristic of the primary application node, as compared to secondaries.

In the event that the primary application node fails, permanently, a secondary application node can be assigned this responsibility by adjusting the list of scheduled jobs on that node to include psupdate .

See Automated node check when using a load balancer for important details on monitoring application nodes status from the load balancer.

See Load Balancer Configuration for Bravura Security Fabric for specific details on configuring a F5 LTM load balancer for Bravura Security Fabric .