🏗️ Distributed Deployment Overview

Enterprise-grade multi-server deployment for maximum scalability and high availability

📋 Introduction

For enterprise environments, Ring2All PBX can be deployed across multiple servers to achieve:

Goal	Solution
High Availability	No single point of failure
Horizontal Scaling	Add servers as capacity grows
Performance Isolation	Separate workloads across servers
Disaster Recovery	Data replication across nodes

🏛️ Architecture Diagram

flowchart TD
    subgraph Clients["Clients & Edge Network"]
        SIP[SIP Endpoints / Hardphones]
        WebRTC[WebRTC / Softphones]
        Trunks[Carrier SIP Trunks]
    end

    subgraph Perimeter["Perimeter & Load Balancing"]
        SBC["Ring2All SBC Cluster<br/>(Kamailio 6.1 + RTPEngine)"]
    end

    subgraph TelephonyCore["Telephony Application Core (N+1)"]
        FS1["Ring2All PBX Node 01<br/>(10,000 Ext / 1,500 Calls)"]
        FS2["Ring2All PBX Node 02<br/>(10,000 Ext / 1,500 Calls)"]
        FSN["Ring2All PBX Node N<br/>(Horizontal Scale)"]
    end

    subgraph StorageData["Distributed Storage & Database Layer"]
        DB[("PostgreSQL 17 HA Cluster<br/>(Patroni + Raft Consensus)")]
        Gluster[("GlusterFS / S3 Cluster<br/>(Voicemail & Call Recordings)")]
    end

    subgraph Management["Management & Billing Subsystems"]
        Admin["Ring2All Web Admin"]
        Portal["User Portal"]
        Switchboard["Switchboard Console"]
        BSS["Ring2All BSS (Carrier Billing)"]
    end

    SIP --> SBC
    WebRTC --> SBC
    Trunks --> SBC

    SBC --> FS1
    SBC --> FS2
    SBC --> FSN

    FS1 --> DB
    FS2 --> DB
    FSN --> DB

    FS1 --> Gluster
    FS2 --> Gluster
    FSN --> Gluster

    Admin --> DB
    Portal --> DB
    Switchboard --> DB
    BSS --> DB

📊 Server Roles & Requirements

Infrastructure Servers

Role	Hostname	IP (Example)	vCPU	RAM	Storage	Packages
Database Node 1	pg-node-01	192.168.10.31	4	16GB	500GB SSD	PostgreSQL 17 + Patroni + Etcd
Database Node 2	pg-node-02	192.168.10.32	4	16GB	500GB SSD	PostgreSQL 17 + Patroni + Etcd
Database Node 3	pg-node-03	192.168.10.33	4	16GB	500GB SSD	PostgreSQL 17 + Patroni + Etcd
File Server 1	fs-node-01	192.168.10.34	2	4GB	1TB+ HDD/SSD	GlusterFS Server
File Server 2	fs-node-02	192.168.10.35	2	4GB	1TB+ HDD/SSD	GlusterFS Server
File Server 3	fs-node-03	192.168.10.36	2	4GB	1TB+ HDD/SSD	GlusterFS Server

Application Servers

Role	Hostname	IP (Example)	vCPU	RAM	Storage	Packages
Admin	admin-node-01	192.168.10.10	4	8GB	50GB	`softswitch-admin`
Portal	portal-node-01	192.168.10.20	2	2GB	20GB	`softswitch-portal`
Switchboard	switch-node-01	192.168.10.30	2	2GB	20GB	`softswitch-switchboard`
API	api-node-01	192.168.10.40	4	8GB	50GB	`softswitch-api`

Telephony Servers (N+1)

Role	Hostname	IP (Example)	vCPU	RAM	Storage	Capacity
Telephony 1	tele-node-01	192.168.10.51	4-16	8-32GB	100GB	10,000 ext / 1,500 calls
Telephony 2	tele-node-02	192.168.10.52	4-16	8-32GB	100GB	10,000 ext / 1,500 calls
Telephony N	tele-node-N	192.168.10.5N	4-16	8-32GB	100GB	10,000 ext / 1,500 calls

📈 Scaling Reference

Telephony Horizontal Scaling

Servers	Total Extensions	Concurrent Calls	Use Case
1	10,000	1,500	Medium Enterprise
2	20,000	3,000	Large Enterprise
3	30,000	4,500	Enterprise+
5	50,000	7,500	Service Provider
10	100,000	15,000	Carrier Grade
20+	200,000+	30,000+	Large Carrier

💡 Key Insight: Each telephony server is independent and connects to the shared database cluster. Add servers as capacity grows without reconfiguration.

🔄 High Availability Features

Database Cluster (PostgreSQL + Patroni)

Feature	Description
Automatic Failover	If primary fails, replica promotes in <30 seconds
Streaming Replication	Real-time data sync (RPO ≈ 0)
Consensus (Etcd)	Distributed leader election
Self-Healing	Automatic replica recovery

File Server Cluster (GlusterFS)

Feature	Description
Replica 3	Every file stored on 3 nodes
Self-Healing	Automatic sync after node recovery
Active-Active	All nodes serve traffic
Client Failover	Automatic redirection if node fails

Application Layer

Feature	Description
Stateless Design	Any API server can handle any request
Load Balancing	HAProxy distributes traffic
Health Checks	Automatic removal of failed nodes

📖 Distributed Installation Guides

Follow these comprehensive guides for each phase of your distributed infrastructure:

Guide	Description
📖 Distributed Cluster Step-by-Step Guide	Complete walkthrough: Patroni PostgreSQL 17, GlusterFS, Web/API, and FreeSWITCH N+1 telephony cluster
📖 Web Cluster & Load Balancing Guide	Multi-server Web GUI and API high availability behind Cloudflare and HAProxy
📖 Ring2All SBC Deployment Guide	Perimeter SIP gateway (Kamailio 6.1 + RTPEngine) with WireGuard mesh to PBX nodes
📖 Ring2All BSS Deployment Guide	Carrier billing engine, real-time OCS rating, and public customer self-care store

🔗 Network Requirements

Internal Network (Private LAN / WireGuard Subnet)

Port	Protocol	Service	Between
5432	TCP	PostgreSQL 17	DB nodes ↔ App/Telephony servers
8008	TCP	Patroni REST API	DB nodes ↔ HAProxy leader check
2379/2380	TCP	Etcd Raft Consensus	DB nodes (peer sync)
5000	TCP	HAProxy Local Write Proxy	Local apps/FreeSWITCH ↔ Patroni Leader
5001	TCP	HAProxy Local Read Proxy	Local apps ↔ Patroni Standby Replicas
6432	TCP	PgBouncer Connection Pooler	FreeSWITCH/ODBC ↔ Local HAProxy
24007-24008	TCP	GlusterFS Daemon	Storage nodes
49152-49251	TCP	GlusterFS Bricks	Storage nodes ↔ Clients (Recordings/Music)
51820	UDP	WireGuard VPN Mesh	Core PBX Nodes ↔ Ring2All SBC

External Network (Perimeter Edge)

Port	Protocol	Service
80/443	TCP	HTTP/HTTPS (Web UI & APIs)
5060	UDP/TCP	SIP Signaling (Kamailio SBC)
5061	TCP	SIP TLS (Kamailio SBC)
16384-32768	UDP	RTP Media Relay (RTPEngine)

🚀 Quick Start Checklist

Network: Private network configured between all servers (192.168.10.0/24)
DNS/Hosts: All servers can resolve each other by hostname
Firewall: Required ports open between servers in nftables
Storage: Dedicated NVMe/SSD disks for databases and distributed recordings
OS: Debian 13 (Trixie) installed on all servers

Next: 📖 Distributed Multi-Server Cluster Step-by-Step Guide