Oracle® Communications Services Gatekeeper System Administrator's Guide Release 5.1 E37531-01 |
|
|
PDF · Mobi · ePub |
This chapter describes how to set up geographically redundant site pairs for Oracle Communications Services Gatekeeper. The attributes and operations supporting geographically redundancy are explained, and a configuration workflow is provided.
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 Service Level Agreements (SLAs), and budgets) necessary for SLA enforcement available at the second, remote, site. For more information about geographic redundancy, see "Redundancy, Load Balancing, and High Availability" in Oracle Communications Services Gatekeeper Concepts Guide.
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.
There are two stages to configuring basic geographic redundancy. Both must be done at each site.
Configure the geographically redundant service.
Define the geomaster site
To use geographic redundancy, each site must be appropriately configured. This is accomplished using the GeoRedundantService. Using this service, you:
Define the ID of the local site in Attribute: GeoSiteId.
Define the number of failed attempts to reach a remote site before an alarm should be raised in Attribute: RemoteSiteReachabilityAlarmThreshold.
Define the remote site in Operation: setSiteAddress.
One site of the site pair must be designated the geomaster site. This is accomplished using the GeoStorageService. Using this service, you:
Define the site that is to serve as the geomaster in Attribute: GeoMasterSiteId
Managed object: Container Services−>GeoRedundantService
MBean Type: com.bea.wlcp.wlng.core.budget.management.configuration.GeoRedundantServiceMBean
Following is a list of attributes and operations for configuration and maintenance:
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".
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.
Scope: Cluster
Signature:
getSiteAddress(Site name: String)
Displays the address of a given remote site. Table 10-1 describes this parameter.
Scope: Cluster
Signature:
listRemoteSites()
Displays a list of registered remote sites.
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.
Table 10-2 describes this parameter.
Scope: Cluster
Signature:
setSiteAddress(Site name: String, Address: String)
Specifies the address of a remote site. Must be done at both sites.
Table 10-3 describes the parameters.
Managed object: Container Services−>GeoStorageService
MBean Type: com.bea.wlcp.wlng.geostorage.management.GeoStorageServiceMBean
Following is a list of attributes and operations for configuration and maintenance:
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.
Note:
If a new site is added to replace a slave site that has failed, it must be added as a slave site. The site that is designated the geomaster site must remain the geomaster site for the lifetime of the site configuration.If a geomaster site fails permanently, this attribute should be set to empty (temporarily terminating georedundancy) and the failed site should be removed from the configuration using the GeoRedundantService. If a replacement site is added to the configuration, the currently operating site must be the geomaster and the replacement site must be added as the slave.
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.
Note:
This operation potentially copies large amounts of data and therefore should not be used during peak traffic hours