Designing Active/Standby InControl Virtual Appliance (ICVA) for Enterprise Environments

Author: Ermias Teffera, (CCIE# 70053)

Introduction

As enterprise networks continue to expand across branch offices, retail locations, manufacturing sites, and mobile deployments, centralized network management becomes a critical component of operational success. Peplink's InControl Virtual Appliance (ICVA) enables organizations to host their own InControl platform within their private infrastructure, providing complete control over management data while maintaining the powerful monitoring, configuration, and reporting capabilities of InControl.

For organizations where management platform availability is mission-critical, a single ICVA instance introduces a potential point of failure. Designing an Active/Standby architecture significantly improves resiliency by ensuring that management services remain available during planned maintenance or unexpected infrastructure failures.

This article discusses the architectural considerations, design principles, and best practices for deploying a highly available ICVA environment.

Why Deploy ICVA Instead of Public InControl aka IC2?

While Peplink's cloud-hosted InControl service is suitable for many deployments, enterprise organizations often require greater control over where management data resides.

Common reasons for deploying ICVA include:

• Compliance with corporate security policies

• Regulatory or data sovereignty requirements

• Private management infrastructure

• Integration with internal authentication systems

• Localized management with reduced dependency on Internet connectivity

ICVA can be hosted on VMware, Hyper-V, KVM, AWS, Azure, and other supported virtualization platforms, allowing organizations to leverage their existing infrastructure investments.

Understanding Active/Standby Architecture

Unlike traditional clustering where multiple nodes actively serve traffic simultaneously, an Active/Standby design keeps one ICVA instance responsible for all production workloads while a secondary appliance remains synchronized and ready to assume operations if necessary.

The architecture typically consists of:

• Primary ICVA

• Standby ICVA

• Shared or replicated database

• Virtual IP (VIP) or DNS-based failover

• External load balancer or HA mechanism

• Shared backup repository

              +----------------------+
              |  Load Balancer / VIP |
              +----------+-----------+
                         |
             -------------------------
             |                       |
      +--------------+       +--------------+
      | Active ICVA  |       | Standby ICVA |
      +--------------+       +--------------+
              |                      |
              +----------+-----------+
                         |
               Database Replication

The goal is to minimize management downtime without requiring changes on managed Peplink devices.

Key Design Considerations

1. Separate Failure Domains

Avoid placing both virtual appliances on the same hypervisor.

Instead, distribute them across:

• Different ESXi hosts

• Different VMware clusters

• Separate Hyper-V hosts

• Separate cloud availability zones

This protects against host failures and maintenance events.

2. Database Protection

The ICVA database stores:

• Organizations

• Groups

• Device inventory

• Configuration templates

• Users

• Historical reports

• Event logs

Because the database represents the operational state of the platform, it should be protected using:

• Database replication

• Frequent snapshots

• Scheduled backups

• Storage redundancy

Recent ICVA releases support both essential configuration backups and consistent database disk backups for supported virtualization platforms.

3. Virtual IP or DNS Failover

Devices should always communicate with a consistent management endpoint.

Recommended approaches include:

• HAProxy

• F5 BIG-IP

• Citrix ADC

• Keepalived

• Floating Virtual IP

• Automated DNS failover

Using a stable endpoint eliminates the need to reconfigure thousands of managed devices after failover.

4. Storage Design

Avoid storing ICVA virtual disks on local storage.

Enterprise deployments should utilize:

• VMware vSAN

• SAN

• NAS

• Azure Managed Disks

• AWS EBS

• Enterprise storage arrays

Storage redundancy is just as important as compute redundancy.

5. Backup Strategy

A resilient ICVA deployment should include multiple layers of protection:

Daily:

• Essential configuration backup

Weekly:

• Database snapshots

Monthly:

• Full VM backup

Before upgrades:

• Manual snapshots of both application and database virtual machines

Peplink recommends maintaining essential data backups because they include the appliance configuration, licensing information, users, organizations, and device configuration data.

Networking Considerations

High availability also depends on proper network design.

Best practices include:

• Redundant upstream connectivity

• Multiple DNS servers

• Reliable NTP sources

• Firewall rules permitting required outbound synchronization

• Low-latency communication between ICVA and the database

Where Internet connectivity is available, ICVA periodically synchronizes service expiration information, firmware metadata, and other platform updates with Peplink's public InControl services.

Monitoring and Health Checks

An HA deployment should continuously monitor:

• CPU utilization

• Memory consumption

• Disk usage

• Database replication status

• Application health

• API responsiveness

• SSL certificate validity

Automated monitoring allows organizations to detect issues before they impact administrators.

Planned Maintenance

One of the primary advantages of an Active/Standby design is simplified maintenance.

Typical workflow:

1. Synchronize the standby appliance.

2. Validate application health.

3. Redirect management traffic to the standby instance.

4. Upgrade the primary appliance.

5. Validate operation.

6. Return production traffic if desired.

This minimizes disruption to network operations teams while maintaining management availability.

Disaster Recovery

High availability protects against hardware failures, but disaster recovery addresses site-level outages.

Enterprise DR planning should include:

• Off-site backups

• Replicated storage

• Secondary data center

• Cloud recovery environment

• Documented recovery procedures

• Regular recovery testing

An effective DR strategy complements an Active/Standby deployment and reduces recovery time objectives (RTO) during major incidents.

Security Best Practices

Protecting the management platform is just as important as protecting the network itself.

Recommended practices include:

• Restrict administrative access

• Use role-based access control

• Enable multi-factor authentication where available

• Use HTTPS with trusted certificates

• Keep ICVA updated

• Secure backup repositories

• Integrate monitoring with SIEM platforms

• Regularly audit administrator accounts

  
  

Conclusion

For enterprise organizations managing hundreds or thousands of Peplink devices, designing an Active/Standby InControl Virtual Appliance environment provides the resilience needed for business-critical network operations.

By separating failure domains, protecting the database, implementing intelligent failover, maintaining robust backup strategies, and continuously monitoring system health, organizations can significantly reduce management downtime while improving operational reliability.

As enterprises continue to expand their WAN infrastructure, investing in a highly available ICVA deployment ensures that centralized management remains secure, resilient, and ready to support future growth.