Skip to main content

Best practice: Where to install the Bravura Security Fabric and database software

Bravura Security Fabric can be installed on the same server as the database, or on a separate server.

If Bravura Security Fabric and the DBMS are installed on a virtual machine, ensure the database is deployed on a disk with high-speed I/0 (not a vmdk file).

Note that two or more Bravura Security Fabric instance nodes may share the database schema. See Installing with a shared schema for more information.

The suggested architecture for smaller Bravura Security Fabric implementations involves running three application nodes, each with its own database server located on the same host. The decision to colocate the backend database services with the application itself requires careful consideration of various factors.

Challenge

Different organizations may evaluate the advantages and disadvantages differently, leading to distinct conclusions.

Best practice solution

Evaluate the following potential advantages and disadvantages to determine the best solution for your organization:

  1. Replication Architecture: If you're using a shared or hybrid schema, the database is typically housed on a separate server because the configuration requires symmetrical setup. This can be viewed as either a disadvantage or an advantage, depending on the context.

  2. Lower Latency: Housing the database on the same server as the application can result in less network traffic, due to the lower latency between the application and the database.

  3. Resource Contention: Having both the application and database on the same server can increase the chances of resource contention.

  4. Security: Co-location can reduce the separation of duties (SoD), which can lower the security. However, in certain situations, a reduced SoD can be beneficial.

  5. Administration: A single administrator can manage the entire stack, allowing for quicker troubleshooting.

  6. Node Portability: Having the application and database on the same server can enhance node portability and facilitate a quicker backup plan.

  7. Health Checks: If both the application and database are on the same server, health checks can monitor both for available space, errors, CPU usage, long processes, and more.

  8. Budget: Co-location can result in slightly lower costs due to savings on an extra OS license, separate resource pools, and the management of an additional server.

  9. Performance: The same performance will be achieved, assuming the database server meets the minimum requirements for the database product.

    By default, the Microsoft database engine will only utilize one CPU core, due to license restrictions – the ability to use more CPU cores incurs additional costs.

  10. The backup process can be simplified by taking a snapshot of the complete server instead of making separate backups of multiple servers. This makes the restore process much simpler.

Regardless of the decision, the backend database must be close to the application nodes it serves. Ideally, it should be in the same data center and, if possible, on the same rack space to minimize latency as much as possible.

See also

See Database Replication Architecture for more information on using a shared or hybrid schema.

In this section: