High Availability options for rConfig
After reading this page, you can tell whether High Availability (HA) is part of rConfig V8 Core, understand the basic HA models rConfig supports, and know where to go for full HA architecture guidance. V8 Core is a single-node deployment, so HA is provided by the Pro, Enterprise, and Vector editions.
What High Availability means for rConfig
Section titled “What High Availability means for rConfig”High Availability keeps network configuration management running when a single server, database, or storage component fails. Organisations adopt it where downtime affects compliance monitoring, change velocity, or service level agreements, and where a single-node deployment cannot meet the required uptime target.
There is no single HA architecture that fits every deployment. The right approach depends on your Recovery Time Objective (RTO), Recovery Point Objective (RPO), existing infrastructure, and operational expertise. Those decisions, and the components that support them, sit with the editions that include HA.
Where V8 Core fits
Section titled “Where V8 Core fits”rConfig V8 Core runs as a single node: one application server, one database, and local or mounted storage. It is well suited to standalone deployments, labs, and smaller estates where a single server meets your availability needs.
V8 Core does not include the failover, clustering, or replication tooling needed for HA. If you need resilience beyond a single node, the higher editions provide it.
HA models in the higher editions
Section titled “HA models in the higher editions”The Pro, Enterprise, and Vector editions support several HA approaches. These are summarised here for context only. See the rConfig product documentation site for full architecture, configuration, and operational detail.
| Model | Summary | Typical fit |
|---|---|---|
| Active/Standby | One active node serves traffic while a standby node takes over on failure, usually via a Virtual IP. | Most production HA deployments. |
| Active/Active | Multiple nodes serve traffic behind a load balancer for load distribution and near-zero-downtime failover. | High request volumes or sub-second RTO targets. |
| Horizontal scaling | Independent rConfig instances each manage a subset of devices, with reporting aggregated externally. | MSPs and large, regionally distributed estates. |
Database resilience (PostgreSQL or MariaDB replication) and shared persistent storage (NFS, GlusterFS, or cloud-native file services) underpin all of these models. They are designed and implemented per deployment rather than enabled by a setting.