System Administrator’s Guide

Setting Up Geographic Redundancy

The following section describes how to set up Oracle Communications Services Gatekeeper geographically redundant site pairs and the maintenance attributes and operations for the geographic redundancy service once it is set up. It also provides a workflow for the configuration:

Introduction

The geographic redundancy service replicates data between two geographically distant sites so that applications can switch from one site to another (for example, in case of the catastrophic failure of one) and still have all the configuration data (account information, system SLAs, and budgets) necessary for SLA enforcement available at the second, remote, site. For more information about geographic redundancy, see section Redundancy, Load Balancing, and High Availability chapter in Oracle Communications Services Gatekeeper Concepts and Architectural Overview.

The sites are set up in pairs. One member of the pair is designated the geomaster, the other the slave. Each geographic site has a name which is used for looking up data relevant to the site pair. The name of the remote site is defined in the local site.

Configuration Workflow

There are two stages to configuring basic geographic redundancy. Both must be done at each site.

Configure Each Site for Geo-Redundancy

To use geographic redundancy, each site must be appropriately configured. This is accomplished using the GeoRedundantService. Using this service, you:

Define the GeoMaster Site

One site of the site pair must be designated the geomaster site. This is accomplished using the GeoStorageService. Using this service, you:

Reference: Attributes and Operations for GeoRedundantService

Managed object: Container ServicesGeoRedundantService

MBean Type: com.bea.wlcp.wlng.core.budget.management.configuration.GeoRedundantServiceMBean

Below is a list of attributes and operations for configuration and maintenance:

Attribute: GeoSiteId

Scope: Cluster

Format: String

Defines the name of this geographic redundant site. Must be done at both sites. This name is used as key for all operations on the remote site - see Operation: setSiteAddress, Operation: getSiteAddress, Operation: removeSite.

Attribute: RemoteSiteReachabilityAlarmThreshold

Scope: Cluster

Format: int

Specifies the number of attempts made by a site to reach its peer site before raising an alarm. Must be done at both sites.

Whenever the peer sites fail to establish a connection the number of times defined in RemoteSiteReachabilityAlarmThreshold, a connection lost alarm is raised.

Operation: getSiteAddress

Scope: Cluster

Signature:

getSiteAddress(Site name: String)

Displays the address of a given remote site.

Operation: listRemoteSites

Scope: Cluster

Signature:

listRemoteSites()

Displays a list of registered remote sites.

Operation: removeSite

Scope: Cluster

Signature:

removeSite(Site name: String)

Removes a site definition for a remote site. If both sites are operational, must be done at both sites

Operation: setSiteAddress

Scope: Cluster

Signature:

setSiteAddress(Site name: String, Address: String)

Specifies the address of a remote site. Must be done at both sites

Reference: Attributes and Operations for GeoStorageService

Managed object: Container ServicesGeoStorageService

MBean Type: com.bea.wlcp.wlng.geostorage.management.GeoStorageServiceMBean

Below is a list of attributes and operations for configuration and maintenance:

Attribute: GeoMasterSiteId

Scope: Cluster

Format: String

Defines the geomaster site. This value must be set at both sites and must be one of the two GeoSiteIds set up using the GeoRedundant service. The geomaster keeps the master copy of all geo-configurable data.

Operation: syncFromGeoMaster

Scope: Cluster

Signature:

syncFromGeoMaster()

Forces the slave to resync the account configuration data with the geomaster. Should only be invoked from the slave site. This is used if, for example, the configuration data of the two sites get out of sync, resulting in multiple out-of-sync alarms.