Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

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 241 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.

Figure 241: Geo-redundancy–Data Replication Between Two Remote SSR 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.

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 241, 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 241, 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.

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_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 master 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)

Modified: 2017-03-07