There are multiple ways to cluster EJBCA and the following sections provide information on clustering with RDS.

Before EJBCA Cloud 2.0, the typical approach was to cluster the local Galera nodes with each other, see Clustering with Galera on Local Nodes. As of EJBCA Cloud version 2.0, you can install directly into a Relational Database Service (RDS) database. This makes clustering and upgrades more straightforward since the data is a single, centralized source of truth.

Clustering with an RDS database is the preferred way to cluster EJBCA. Using the configuration wizard, you can directly install into an RDS database, allowing you to point nodes to this new centralized database and load balance between them. For more information, see Clustering with RDS.

Doing local Galera Node clusters is not recommended by EJBCA professionals.  Clustering this way brings many system management aspects that must be considered:

  1. Galera node upgrades - How are database upgrades being handled?
  2. Maintenance of application servers - When rebooting an application server for any reason you are also rebooting a database replica.
  3. Who maintains the expertise to fix a node when a replication error occurs.  Many times configurations on nodes can get out of sync and this is not notices until a restart happens.
  4. How are full state transfers handled?  If a node is down long term, is an expert on hand that can handle the difference between a Full and Incremental State Transfer (SST vs IST).

Recommendations are to install to a Cloud Hosted database like RDS or Aurora.  This brings in a solid, cloud managed database with all of the availability, backup and patching methods delivered by cloud providers.

A selection can also be made to install into an existing RDS database using the database configuration wizard. For more information, see Wizard Based Configuration in Clustering with RDS.