Provision a highly available session border controller
Session border controllers (SBCs) enable the delivery of secure, high-quality, interactive voice and data traffic across multiple IP networks.
SBCs are deployed at the borders between IP networks. Enterprises can use SBCs to interconnect internal communication networks, connect to a wide area service designed for interactive communications (such as a SIP trunk), and so on. SBCs can also be deployed between two service providers, or between a service provider and its customers.
- Security
- Interoperability and service reach maximization
- Quality of experience (QoE), availability, and service-level agreement (SLA) assurance
- Service revenue optimization and cost management
- Regulatory compliance
Oracle Communications Session Border Controller is a powerful, full-featured software that you can deploy on Oracle Cloud Infrastructure. The generation-2 hardware underlying Oracle Cloud Infrastructure uses non-oversubscribed networks and provides the computing power necessary for controlling session-based communications, without adding latency, jitter, or delay to the bidirectional media flows that constitute such communications.
Architecture
This reference architecture contains an active-standby pair of Oracle Communications Session Border Controller instances, which are deployed in different fault domains in a single availability domain in an Oracle Cloud Infrastructure region. In regions that have multiple availability domains, you can distribute the SBC instances across two availability domains.
The following diagram illustrates this architecture.
Description of the illustration sbc-oc.png
The architecture has the following components:
- Primary and standby SBC nodes
These are compute instances that host the Oracle Communications Session Border Controller. In this reference architecture, both the SBC nodes are attached to the same subnet, and they're deployed within a single availability domain. You can choose to attach the SBC nodes in different subnets. In a region that has multiple availability domains, you can deploy them in separate availability domains.
- Bastion host
The bastion host is a compute instance attached to a private subnet. It provides secure administrative access to the SBC nodes.
You can install third-party software, such as Sippy, to manage the SBC nodes.
- Virtual cloud network (VCN) and subnets
This reference architecture has a single VCN, with two public subnets and two private subnets.
Each SBC node has VNICs in all the four subnets. The following table summarizes the network distribution and the purpose of the four VNICs.VNIC and Subnet Purpose Primary VNIC0 in private subnet WanPort0 Administrative access to the SBC instances. Secondary VNIC1 in public subnet Media 0 Carries packets with a voice data payload. Secondary VNIC2 in public subnet Media 10 Carries signaling traffic payload for the voice sessions. Secondary VNIC3 in a private subnet Carries live traffic between the primary and standby SBCs to monitor the health of these controllers. If there's a failure in the primary SBC, it transfers active voice call-related information to the standby SBC.
- Security lists
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- NAT gateway
The NAT gateway enables access from private nodes to hosts on the internet, such as for downloading patches and updates to the SBC nodes or the bastion/Sippy node.
- Service gateway
The service gateway provides access from the VCN to Oracle Cloud Infrastructure Object Storage, for storing logs and other data.
- Object Storage
The Oracle Cloud Infrastructure Object Storage service is an internet-scale, high-performance storage platform that offers reliable and cost-efficient data durability. You can use it to store logs and other data.
- Availability domains
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domains
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you place Compute instances across multiple fault domains, applications can tolerate physical server failure, system maintenance, and many common networking and power failures inside the availability domain.
Recommendations
Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.
- Sippy/bastion host
Use a VM.Standard.2.4 compute shape. This host is used to access the SBC nodes and to run the management software, such as Sippy.
- Primary and standby SBC nodes
Use the VM.Standard2.24 shape, which provides 24 OCPUs and 320 GB of RAM. It also provides 24.6 Gbps network bandwidth. If the deployment requires more bandwidth, then consider using BM.Standard2.52, which provides 52 OCPUs, 768 GB RAM, and 2 x 25-Gbps network bandwidth.
- Object Storage
Use Oracle Cloud Infrastructure Object Storage to store logs and other data.
- VCN
When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range large enough for the required IP addresses. Use an address space that falls within the standard private IP address blocks.
Select an address range that doesn’t overlap with your on-premises network, so that you can set up a connection between the VCN and your on-premises network later, if necessary.
After you create a VCN, you can't change its address range.
When you design the subnets, consider your functionality and security requirements. Attach all the compute instances within the same tier or role to the same subnet.
Use regional subnets.
- Security lists
Use security lists to define ingress and egress rules that apply to the entire subnet.
Considerations
- Performance and cost
Oracle Cloud Infrastructure offers compute shapes that cater to a wide range of applications and use cases. Choose the shapes for your compute instances carefully. Select shapes that provide optimal performance for your load at the lowest cost.
- Availability
Consider using a high-availability option based on your deployment requirements and your region. The options include distributing resources across multiple availability domains in a region, and distributing resources across the fault domains within an availability domain.
- Monitoring and alerts
Set up monitoring and alerts on CPU and memory usage for your nodes, so that you can scale the shape up or down as needed.