Skip to main content

Why is replication required?

There are quite a few reasons why an enterprise application like Bravura Security Fabric requires scalability.

Two or more replicated nodes

If there is a lot of interaction expected from users, the web-based interface processing will have to require attention: OS processes and IIS concomitant processing and other OS resource limits can be reached.

In that case, adding nodes in shared schema would be the solution; that is 2 or more nodes connecting to the same database.

At least two replicated full nodes (application+DB) are required if:

  • Geographical distribution and disaster failure have to be considered, (one node per Internet-routing geographical area, at a minimum).

  • Resource-consuming functionality can be segregated on separate dedicated nodes:

    • psupdate and other discovery processes.

    • User interaction so psupdate and other automated processes do not slow it down.

    • Disaster recovery (one database node in a different data center).

    • For Bravura Privilege , different managed-system-policy processing can be assigned to different nodes.

    • Storage-intensive session monitoring can be limited to one (hybrid architecture) database node that does not do anything else.

    • For Bravura Identity , any resource-intensive automation can be processed on a (hybrid) node that does not do anything else, if it does not depend on the most recent data processed on other nodes.

Hybrid architecture replication

After adding a certain number of database nodes, the transactional overhead between linked iddb services reduces the additional resource benefits.

  • After five or six nodes in direct (1:1) replication, the added benefits are negligible.

  • The upper number of nodes that allow for scaling up of the instance, depends on the characteristics of the available network between the nodes (latency and in some cases, bandwidth; see the sections on those topics).

  • For that reason, hybrid architecture replication can be added; x sets of (y nodes connected to the same database) can perform better than x*y nodes in direct replication.

  • Hybrid architecture combines the benefits of direct data replication with those of shared schema, to provide resources for critical instances, or instances serving many users (in the hundreds of thousands or more), or with very complicated, resource-intensive solutions.

One database node, no replication

On small, low use, low automation instances, resources can be saved by placing the database server on the application server (Database node A, primary-only, with its own database, no replication):

  • This removes network latency from App-DB communication, speeding up the instance.

  • It also makes Bravura Security Fabric easier to maintain (including backups).

  • Even if there is not much activity (for instances serving under 5000 profiles with few targets), the data on a single node with the database running on the same server will be increasing to the point where the database engine and the application will start competing for resources. At that point a separate database server will be required - still no replication is involved.

However, this one-node topology presents a single point of failure, and is not recommended for mission-critical solutions.

Not all configuration changes get replication between nodes

When working in a replicated environment, making a configuration change on the primary node will usually replicate the change to the other application nodes and proxies.

  • Most system variables and other backend database changes are replicated instantly. External database and component changes are sent every five minutes by default. This interval can be configured in Windows Task Scheduler > Library > Bravura Security external database replication.

  • Changes to instance files and registry, including some system variables, are sent once a day, or whenever PSUPDATE in Manage the system > Maintenance > Scheduled jobs is configured to run:

    • These are sent to secondary nodes from the updinst utility on the primary node, sending to the idfilerep service on each secondary node.

    • To proxies with the updproxy utility on the primary node, sending to the psproxy service on each proxy.

  • Some changes are not replicated at all:

    • Most files from the instance directory are replicated. The <Program Files>\Common Files\Bravura Security\ files are not, so Connector Packs have to be installed on each secondary node and each proxy node separately.

    • To see the blacklist(s) for file/registry replication, open a command prompt in the instance’s util\ directory and run updinst -showconfig .

    • The blacklist for updproxy is built into the binary. There is no config file. Contact support@bravurasecurity.com with the Bravura Security Fabric version installed on your instance if you want to know that blacklist.

Keep this in mind and document your configuration for the Bravura Security maintenance team to be aware of which specific configuration changes will be replicated to other nodes, and when.

In this section: