logotype
Our Sales team will contact you after filling out the form.
Select solution:

Cookie anyone?

We use cookies to personalise content and ads, to provide social media features and to analyse our traffic. You consent to our cookies if you continue to use our website. learn more

Accept

High Availability Deployment Example

IceWarp can be deployed in a high-availability (HA) architecture designed to keep services online during component failures. The model below is a common approach for production environments and can be adapted to different sizes and requirements.

For a detailed description of a sample setup, please see IceWarp KB article

1) Frontend Load Balancers
(VIP failover)

Two load balancers provide a single, stable entry point for users via a floating Virtual IP (VIP).

  • One load balancer is active and owns the VIP.
  • The second is standby, continuously monitoring the active node via health checks/heartbeat.
  • If the active load balancer fails, the VIP automatically fails over to the standby node.
  • Users always connect to the same VIP, so failover is transparent.

Details on this layer can be found here.

2) Application Tier (Active-Active)

Behind the load balancers, IceWarp runs on two identical application servers operating in parallel.

  • Traffic is distributed across both nodes using standard load-balancing methods.
  • Health checks ensure only healthy nodes receive traffic.
  • If one application server becomes unavailable, requests are automatically routed to the remaining node, maintaining service continuity (with reduced capacity until recovery).

Details on this layer can be found here.

3) Database High Availability

IceWarp connects to a high-availability MySQL backend, implemented using replication or a MySQL cluster solution.

  • Typical options include primary–replica replication or a clustered MySQL setup (e.g., Percona XtraDB Cluster).
  • The application connects through a stable database endpoint, allowing database failover to occur with minimal or no impact to users.

More information can be found here.

4) Shared Storage (NFS)

For filesystem-based data (mail storage, documents, uploads, etc.), both application servers access a shared storage layer using NFS.

  • Ensures consistent access to the same data regardless of which application node handles a request.
  • The storage layer should be deployed with redundancy (for example via storage replication) to avoid becoming a single point of failure.

A sample solution can be found here.

Optional: Redis/KeyDB for Session Storage

For environments that benefit from centralized session handling, Redis or KeyDB can be added.

  • Session data is stored in Redis/KeyDB instead of on shared storage.
  • Can improve performance and scalability.
  • For HA, Redis/KeyDB should be deployed in a replicated or clustered configuration.

More information can be found here.