Skip to content

rConfig - HA options overview

2 mins V7 Enterprise & Vector

High Availability (HA) Options for rConfig Deployments

rConfig is designed to be flexible and scalable for diverse customer environments. While High Availability (HA) requirements vary depending on internal SLAs and business priorities, this document outlines the most common approaches and key considerations when designing a resilient rConfig deployment.

⚠️ Important: HA configurations are available for rConfig Enterprise and rConfig Vector licenses only. All scenarios typically require a tailored approach, including Professional Services support.

🔍 Understanding High Availability for rConfig

There is no one-size-fits-all HA architecture for rConfig. The correct approach depends on:

  • Internal SLA objectives (RTO/RPO)
  • Level of automation and fault tolerance required
  • Existing infrastructure and operational team capabilities

Our focus is on aligning with business requirements, not just technical preferences.

We can support Active/Active front-end (load-balanced) deployments, but it’s a more complex and costly setup, requiring significant planning and customisation. This is typically delivered via Professional Services under an Enterprise or Vector license.

Considerations:

  • Requires sticky sessions or external session storage
  • Complicates failover and operational consistency
  • Adds overhead with shared persistent data storage and task queuing

Unless your environment absolutely requires Active/Active for uptime or compliance reasons, we recommend Active/Standby (see below) for most deployments.

✅ Recommended: Active/Standby Setup

This is the most commonly supported HA model.

Key Components:

  • Two rConfig nodes: one active, one standby
  • Failover handled via keepalived, VIP, or corosync/pacemaker
  • Shared /persistentData volume between nodes
  • Application-level monitoring (optional)

Why Active/Standby?

  • Simpler to deploy and operate
  • Ideal for environments with high availability needs, without unnecessary complexity
  • Supports automated or manual failover models

🗃 Database High Availability

rConfig supports PostgreSQL and MariaDB, and both can be deployed in HA mode depending on your chosen stack.

PostgreSQL Options:

  • Streaming replication with automatic failover (e.g., Patroni or repmgr)
  • Managed HA services like AWS RDS or Azure PostgreSQL
  • PgBouncer or HAProxy as smart proxies (optional)

MariaDB Options:

  • Master/Replica replication or Galera Cluster
  • Failover using a VIP or proxy routing layer
  • Compatible with most managed MariaDB HA offerings

No special rConfig DB configuration is required — just ensure rConfig points to a consistent writable primary node.

📦 Storage: /persistentData Directory

rConfig requires persistent storage for backups, configuration history, compliance results, and logs. This must be:

  • Replicated or shared across nodes (e.g. NFS, GlusterFS, or EFS)
  • Mounted identically on each node at /persistentData
  • Resilient to failover events without data loss

🌐 Horizontal Scaling (Without Central Manager)

For teams not using rConfig Vector Central Manager but needing scalability, it’s possible to distribute inventory across multiple standalone rConfig servers (v7 or v8).

How it Works:

  • Each instance operates independently but manages a subset of devices
  • Use tags, regions, or functional groupings to segment inventory
  • External tooling (e.g. Git, Zabbix, API integrations) can unify compliance or reporting

This model is ideal for:

  • MSP environments with isolated customer segments
  • Large-scale deployments that don’t require full multi-tenancy
  • Environments preferring decentralised control

📈 Monitoring and Automation

To support HA or distributed setups, monitoring and alerting is key:

  • Node Health: CPU, memory, disk
  • Service Uptime: web app, config downloads, compliance jobs
  • Database & Storage: latency, I/O, failover triggers

Integrate with Zabbix, Prometheus, or your existing stack. rConfig does not natively handle failover logic — external orchestration is advised.

🤝 Next Steps

To design the right HA or scaled setup for your needs:

  1. Define your business SLAs
  2. Identify infrastructure preferences and constraints
  3. Engage with us to plan a deployment suited to your environment

We’re happy to provide architectural guidance and implementation assistance as part of your Enterprise or Vector subscription with Professional Services.