Designing ICVA Database Replication for High Availability and Disaster Recovery

Author: Ermias Teffera, (CCIE# 70053)

Introduction

Modern enterprise networks are no longer confined to a single location. Organizations commonly deploy infrastructure across multiple campuses, branch offices, data centers, and cloud environments. While network redundancy has become standard practice, many organizations overlook an equally important component—the management platform.

For Peplink deployments, the InControl Virtual Appliance (ICVA) serves as the centralized management platform responsible for monitoring, configuration management, firmware distribution, reporting, and orchestration of thousands of devices. At the heart of ICVA is the InControl Database (ICDB), which stores the operational state of the management environment.

A common question among architects designing highly available infrastructures is:

Should we implement database replication, or is a traditional Disaster Recovery (DR) solution sufficient?

The answer depends on business requirements, Recovery Point Objectives (RPO), Recovery Time Objectives (RTO), operational complexity, and acceptable downtime. This article explores both approaches and provides guidance on selecting the right architecture.

Understanding the ICVA Architecture

Every ICVA deployment consists of two major components:

ICVA Application Server

The ICVA virtual machine hosts the InControl application responsible for:

• Device management

• Centralized configuration

• Firmware deployment

• SpeedFusion orchestration

• User authentication

• Reporting and analytics

• Monitoring and alerting

Think of the ICVA as the brain that communicates with every managed Peplink appliance.

ICDB Database Server

The ICDB virtual machine hosts the database that stores the persistent operational data required by ICVA.

Without the database, the application has no knowledge of:

• Managed devices

• User accounts

• Device groups

• Policies

• Templates

• Historical reports

• Configuration history

Although the routers continue forwarding traffic independently, centralized management depends entirely on the ICDB.

Why the Database Matters

Imagine an organization managing hundreds of branch routers spread across the country.

Every day administrators perform activities such as:

• Adding new devices

• Building SpeedFusion topologies

• Updating firewall policies

• Creating configuration templates

• Assigning licenses

• Organizing device groups

• Monitoring WAN utilization

• Generating executive reports

These changes represent valuable operational information.

Losing the ICDB means losing access to that centralized management state until it can be recovered.

Traditional Disaster Recovery

The simplest design relies on scheduled backups.

Primary Site

ICVA
 │
ICDB
 │
Scheduled Backup
 │
Off-site Storage

When the primary site experiences a catastrophic failure:

1. Deploy replacement virtual machines.

2. Restore the ICVA.

3. Restore the ICDB.

4. Update DNS or management records.

5. Devices reconnect.

This design is simple, inexpensive, and easy to maintain.

However, it introduces one significant limitation.

Understanding Recovery Point Objective (RPO)

Assume backups occur every six hours.

08:00 AM

• Backup completed.

09:15 AM

• Administrator adds 30 branch routers.

10:30 AM

• New SpeedFusion profiles created.

12:00 PM

• Firewall templates updated.

12:30 PM

• Primary site suffers a complete failure.

  
  

When the backup is restored, the recovered environment reflects the state of the system at 08:00 AM.

Every change made afterward must be recreated manually.

This potential loss of management data is known as the Recovery Point Objective (RPO).

The longer the backup interval, the greater the potential loss.

Database Replication

Database replication addresses this limitation by continuously synchronizing the ICDB to a secondary database.

Primary Site

ICVA1
 │
ICDB1
 │
Continuous Replication
 │
ICDB2
 │
ICVA2 (Standby)

Instead of copying data every few hours, every database transaction is replicated to the standby database almost immediately.

This dramatically reduces potential data loss.

Benefits of Database Replication

Nearly Zero Data Loss

Configuration changes made moments before a failure are already available on the secondary database.

Faster Recovery

Instead of restoring large database backups, administrators simply activate the standby ICVA.

Recovery becomes much faster.

Operational Continuity

Administrators retain:

• Device inventory

• Templates

• Policies

• Historical reports

• User accounts

• Configuration history

without rebuilding the environment.

Better Support for Enterprise Environments

Large organizations with hundreds or thousands of devices benefit significantly because management continuity becomes nearly seamless.

The Cost of Replication

Replication is not without trade-offs.

It introduces additional architectural complexity.

Administrators must design for:

• Database synchronization

• Replication monitoring

• Network latency

• Split-brain prevention

• Failover procedures

• DNS updates

• Secondary site validation

The solution becomes considerably more sophisticated than a simple backup strategy.

Active vs. Standby

One common misconception is that both ICVA servers should actively manage devices simultaneously.

In practice, many enterprise deployments use an Active/Standby model.

Primary Site

ICVA1
 │
ICDB1
 │
Replication
 │
ICDB2

Secondary Site

ICVA2 (Standby)

Only the primary ICVA manages devices.

The secondary environment remains synchronized and ready for activation during a disaster.

This simplifies operations while still providing excellent resiliency.

DNS-Based Failover

A clean failover strategy uses DNS rather than static IP addresses.

Instead of pointing devices directly to an IP address, they communicate using a Fully Qualified Domain Name (FQDN).

Example:

icva.company.com

During normal operation:

icva.company.com
↓

Primary ICVA

During a disaster:

icva.company.com
↓

Secondary ICVA

Once DNS is updated, managed devices reconnect automatically without requiring individual reconfiguration.

When Traditional Disaster Recovery Is Enough

Not every organization needs database replication.

Backup-based disaster recovery is often sufficient when:

• The environment is relatively small.

• Configuration changes are infrequent.

• Downtime is acceptable.

• Losing several hours of management changes is acceptable.

• Simplicity is preferred over automation.

For many organizations, this approach provides an excellent balance between cost and resilience.

When Database Replication Makes Sense

Replication becomes increasingly valuable when:

• Hundreds or thousands of devices are managed.

• Configuration changes occur daily.

• Recovery time must be minimized.

• Management availability is considered mission-critical.

• Operational continuity is a business requirement.

These environments benefit greatly from continuous synchronization.

Choosing the Right Design

There is no universally correct architecture.

The correct design depends on answering four questions:

1. How much management data can be lost?

2. How quickly must management services be restored?

3. How much operational complexity is acceptable?

4. What budget is available for high availability?

These answers determine whether a backup-based disaster recovery solution or continuous database replication is the better choice.

Final Thoughts

One of the biggest misconceptions surrounding ICVA deployments is that routers stop forwarding traffic when the management platform becomes unavailable. They do not.

Peplink routers continue forwarding traffic using their existing configurations.

What is affected is centralized management, visibility, reporting, configuration management, and orchestration.

For organizations that rely heavily on centralized operations, restoring these capabilities quickly is essential.

Database replication is not about keeping packets flowing, it is about keeping operations running.

A well-designed ICVA environment should balance availability, recoverability, operational simplicity, and business requirements, rather than pursuing high availability simply for the sake of complexity.