Geo-Redundancy Considerations: Before Your Begin

6-12 Oracle WebLogic Communications Server Administration Guide ■ Geo-Redundancy is not transparent to the application; in most cases the application must be designed to use SetPersist appropriately, and the developer must consider the volume of state that the application will queue for replication between sites ■ SetPersist should be used within the application code to selectively identify dialog states that will be long-lived ■ Given the time it generally takes to route traffic to a secondary site, any application that replicates state more frequently will unnecessarily saturate the JMS queue and site interconnect ■ Tuning of JMS to the specific application environment is required: Serialization options, message batching, reliable delivery options and queue size are all variable, depending on the specific application and site characteristics ■ Geo-Redundancy default behavior is to replicate all dialog state changes when Geo-Redundancy is enabled for the container this is not recommended for production deployments ■ Given the time it generally takes to route traffic to a secondary site, any application that replicates state more frequently will unnecessarily saturate the site interconnect ■ SetPersist should be used within the application code to selectively identify dialog states that will be long-lived longer than ~20-30 seconds would be a reasonable threshold

6.6 Using Geographically-Redundant SIP Data Tiers

The basic call state replication functionality available in the Oracle WebLogic Communication Services SIP data tier provides excellent failover capabilities for a single site installation. However, the active replication performed within the SIP data tier requires high network bandwidth in order to meet the latency performance needs of most production networks. This bandwidth requirement makes a single SIP data tier cluster unsuitable for replicating data over large distances, such as from one regional data center to another. The Oracle WebLogic Communication Services geographic persistence feature enables you to replica call state transactions across multiple Oracle WebLogic Communication Services installations multiple Administrative domains or sites. A geographically-redundant configuration minimizes dropped calls in the event of a catastrophic failure of an entire site, for example due to an extended, regional power outage. Configuring SIP Data Tier Partitions and Replicas 6-13 Figure 6–3 Oracle WebLogic Communication Services Geographic Persistence

6.6.1 Example Domain Configurations

A secondary Oracle WebLogic Communication Services domain that persists data from another domain may itself process SIP traffic, or it may exist solely as an active standby domain. In the most common configuration, two sites are configured to replicate each others call state data, with each site processing its own local SIP traffic. The administrator can then use either domain as the secondary site should one of domains fail. Figure 6–4 Common Geographically-Redundant Configuration An alternate configuration utilizes a single domain that persists data from multiple, other sites, acting as the secondary for those sites. Although the secondary site in this configuration can also process its own, local SIP traffic, keep in mind that the resource requirements of the site may be considerable because of the need to persist active traffic from several other installations.