Data Replication Between Two Different or Remote SSR Clusters

The SBR Carrier software supports the Geo-redundancy feature that allows data to be replicated among nodes of two remote SSR clusters located in different geographical locations. The Geo-redundancy feature provides a consolidated session store, enabling all sessions from a geographically diverse system to be accessed from a single database. Figure 242 represents the Geo-redundancy environment. The SBR Carrier uses the Geo-redundancy plug-in to optimize data replication. The Geo-redundancy plug-in is responsible for sending and receiving replication packets between clusters.

Geo-redundancy–Data Replication
Between Two Remote SSR Clusters

Note

The Geo-redundancy feature is supported between two SSR clusters only if both SSR clusters have the same CST schema.

Note

When SBR Carrier is configured with the Geo-redundancy feature, SBR Carrier supports up to 3000 transactions per second at 0.10 latency without affecting accounting.

Configuring the Client Component and Server Component

The client component refers to a local cluster, which replicates session information to a remote cluster that is located geographically apart from the local cluster. For example, if the session information of Cluster RED is to be replicated to Cluster BLUE as shown in Figure 242, then Cluster RED is considered as the Geo-redundancy client for Cluster BLUE. The client component is enabled by default in RADIUS front ends of the clusters. You can configure the client component by defining the parameters in the [ClientSettings] section of the georedSess.ses file. For complete details about the parameters of the [ClientSettings] section, see the [ClientSettings] Section in the SBR Carrier Reference Guide.

The server component refers to a remote cluster to which the session information is replicated from the local cluster. For example, if the session information of Cluster RED is to be replicated to Cluster BLUE as shown in Figure 242, then Cluster BLUE is considered as the Geo-redundancy server for Cluster RED. The server component is enabled by default in RADIUS front ends of the clusters. You can configure the server component by defining the parameters in the [ServerSettings] section of the georedSess.ses file. For complete details about the parameters of the [ServerSettings] section, see the [ServerSettings] Section in the SBR Carrier Reference Guide.

To enable a Geo-redundancy server to match incoming accounting requests to replicated session records using the Class attribute (transaction ID), you must configure the spi.ini file on each SBR Carrier server with the IP addresses of all the SBR Carrier servers that might receive accounting requests. For more information about how to configure the spi.ini file, see the spi.ini File section in the SBR Carrier Reference Guide.

Note

The Geo-redundancy feature is disabled if both the client and server components are disabled.

List of CST Fields That Can Be Replicated Across SSR Clusters

The following CST fields can be replicated across SSR clusters:

System core fields:
- Sbr_UniqueSessionId
- Sbr_CreationTime
- Sbr_ExpirationTime
- Sbr_Ipv4Address
- Sbr_Ipv6Address
- Sbr_IpPoolOrdinal
- Sbr_NasName
- Sbr_SessionState
- Sbr_UserConcurrencyId
- Sbr_3gpp2ReqType
- Sbr_WimaxClientType
- Sbr_3gpp2HomeAgentAddr
- Sbr_AcctAutoStop
- Sbr_ClassAttribute
System optional fields:
- Sbr_UserName
- Sbr_AcctSessionId
- Sbr_TransactionId
- Sbr_NasPortType
- Sbr_NasPort
- Sbr_CallingStationId
- Sbr_CalledStationId
- Sbr_MobileCorrelationId
- Sbr_Ipv6InterfaceId
- Sbr_Ipv6Prefix
- Sbr_NasIpv4Address
- Sbr_NasIpv6Address
- Sbr_NasClientName
- Sbr_NasDeviceModel
- Sbr_ProxyState
- Sbr_ProxyRealm
Admin radattr fields:
- FunkOuterUserName
- AcctMultiSessionId

Possible Uses and Limitations of the Geo-redundancy Feature

This section lists the possible uses and limitations of the Geo-redundancy feature.

The Geo-redundancy feature could be used to perform the following tasks:

Consolidating session information across different SSR clusters in a single entity
Replicating selective information about a user session from a CST
Applying policies on the basis of the roaming facility
Regulating traffic on the basis of volume
Limiting the number of sessions per user who roams between multiple clusters
Backing up intelligent data without using a separate physical backup cluster
Replicating session information from multiple standalone SBRs to a single SSR cluster
Replicating data between Linux-based SSR and Solaris-based SSR, or vice versa
Supporting peer-to-peer cluster replication and hierarchical primary cluster replication

The Geo-redundancy feature has the following limitations:

The Geo-redundancy feature does not support multiple-to-multiple cluster replication.
IPv6 hosts cannot be specified as the Geo-redundancy server or client.
The following information cannot be replicated:
- User concurrency table
- IP pool and address information
- SIM session information
- Custom SSR fields
- Worldwide Interoperability for Microwave Access (WiMAX)