High Availability Deployment Architecture Across Regions

You can deploy two sets of NovoOne clusters in different regions as a disaster recovery pair. In the event that the primary clusters fails, cluster failover can switch the telephony services to the secondary clusters in the other site, ensuring that your business calls can continue as usual.

Architecture

NovoOne adopts a cloud-native deployment architecture based on Kubernetes. This leverages container orchestration to support elastic workload scheduling, self-healing, and centralized resource management, supporting the stability and scalability of the overall call service.

The figure below shows the High Availability (HA) architecture of NovoOne across regions.

Within this architecture, two identical HA cluster sets (each contains one Load Balancer Cluster and one Kubernetes Cluster) are required to be deployed across two separate regions. One set acts as the primary cluster set, while the other serves as the secondary cluster set. All types of clients exchange service traffic exclusively with the primary cluster set.

For more information about the primary‑secondary working mode and failover procedures, see Cross‑Region Failover; For more information about processing strategy of service traffic between clients and the primary cluster set, see Traffic Processing.

Cross‑Region Failover
The two cluster sets need to be integrate with third‑party object storage (e.g. Amazon S3 or S3-compatible object storage) for data persistence. While the primary cluster set is active, its data is backed up to the third‑party object storage in real time.
Once the primary cluster set fails, perform cluster failover via the CNPG manager deployed in the secondary cluster set and update domain name resolution on your DNS server.
Note: CNPG Manager is a controller component deployed per cluster set to manage PostgreSQL cluster lifecycles, instance failover, streaming replication, and more.

Data backed in object storage is restored to the secondary cluster set, then the secondary cluster set automatically establishes PG‑HA capability and takes over service traffic to complete the primary‑secondary switchover.

Traffic Processing (Take One Region As An Example)
The supported client types, traffic types, traffic load balancing and traffic routing rules are described below:
Traffic source
  • Trunk Provider (ITSP): ITSP sends SIP signaling traffic and RTP media traffic for inbound and outbound PSTN calls.
  • SIP Endpoints: SIP endpoints include NovoOne Mobile Client and IP Phone. The endpoints send SIP signaling traffic and RTP media traffic for endpoint registration and call-related operations.
  • HTTPS Clients: HTTPS clients include NovoOne Platform, NovoOne Tenant, NovoOne Web Client, and Third-party platform integrated with NovoOne API. These clients send HTTPS traffic for web access, management operations, and API-based interactions.

Traffic loading balancing

All SIP signaling traffic and HTTPS traffic are routed to the Load Balancer Cluster, which has a fixed public IP address. This self-built cluster consists of two load balancer nodes (physical or virtual servers) - an active node and a standby node, providing high availability through failover.

Before forwarding ingress traffic to the Kubernetes Cluster, the active load balancer in the cluster runs health checks on backend services and distributes the traffic.

Traffic routing

Original RTP media traffic from traffic sources, together with SIP signaling traffic and HTTPS traffic forwarded by the Load Balancer Cluster, are routed to the Kubernetes Cluster and processed by corresponding components.

The cluster consists of four network-connected nodes (physical or virtual servers), with each node assigned a dedicated fixed public IP address, and all components run as Pods (the smallest deployable unit in Kubernetes) on these nodes.
Note: Double running Pods are deployed for each component type, delivering system high availability and fast responses to user requests. If one Pod of a component type fails, other running Pod instances of the same component type remain unaffected.

The cluster can schedule Pods to any node to meet the applicable scheduling requirements and enable traffic transmission between components hosted on different nodes.

Call limit

NovoOne adopting this deployment architecture supports up to 100 concurrent calls. To achieve higher call concurrency volumes, contact Yeastar Support to scale the nodes for both the primary cluster set and the secondary cluster set.