datatier.xml Configuration File Configuration Requirements and Restrictions

Configuring SIP Data Tier Partitions and Replicas 6-3 Figure 6–1 Administration Console Display of SIP Data Tier Configuration Read-Only

6.2 Best Practices for Configuring and Managing SIP Data Tier Servers

Adding replicas can increase reliability for the system as a whole, but keep in mind that each additional server in a partition requires additional network bandwidth to manage the replicated data. With three replicas in a partition, each transaction that modifies the call state updates data on three different servers. To ensure high reliability when using replicas, always ensure that server instances in the same partition reside on different machines. Hosting two or more replicas on the same machine leaves all of the hosted replicas vulnerable to a machine or network failure. SIP data tier servers can have one of three different statuses: ■ ONLINE—indicates that the server is available for managing call state transactions. ■ OFFLINE—indicates that the server is shut down or unavailable. ■ ONLINE_LOCK_AUTHORITY_ONLY—indicates that the server was rebooted and is currently being updated from other replicas with the current call state data. A recovering server cannot yet process call state transactions, because it does not maintain a full copy of the call state managed by the partition. If you need to take a SIP data tier server instance offline for scheduled maintenance, make sure that at least one other server in the same partition is active. If you shut down an active server and all other servers in the partition are offline or recovering, you will lose a portion of the active call state. Oracle WebLogic Communication Services automatically divides the call state evenly over all configured partitions.

6.3 Example SIP Data Tier Configurations and Configuration Files

The sections that follow describe some common Oracle WebLogic Communication Services installations that utilize a separate SIP data tier. 6-4 Oracle WebLogic Communications Server Administration Guide

6.3.1 SIP Data Tier with One Partition

A single-partition, single-server SIP data tier represents the simplest data tier configuration. Example 6–1 shows a SIP data tier configuration for a single-server deployment. Example 6–1 SIP Data Tier Configuration for Small Deployment ?xml version=1.0 encoding=UTF-8? data-tier xmlns=http:www.bea.comnswlcpwlss300 partition namepart-1name server-namereplica1server-name partition data-tier To add a replica to an existing partition, simply define a second server-name entry in the same partition. For example, the datatier.xml configuration file shown in Example 6–2 recreates a two-replica configuration. Example 6–2 SIP Data Tier Configuration for Small Deployment with Replication ?xml version=1.0 encoding=UTF-8? data-tier xmlns=http:www.bea.comnswlcpwlss300 partition namePartition0name server-nameDataNode0-0server-name server-nameDataNode0-1server-name partition data-tier

6.3.2 SIP Data Tier with Two Partitions

Multiple partitions can be easily created by defining multiple partition entries in datatier.xml, as shown in Example 6–3 . Example 6–3 Two-Partition SIP Data Tier Configuration ?xml version=1.0 encoding=UTF-8? data-tier xmlns=http:www.bea.comnswlcpwlss300 partition namePartition0name server-nameDataNode0-0server-name partition partition namePartition1name server-nameDataNode1-0server-name partition data-tier

6.3.3 SIP Data Tier with Two Partitions and Two Replicas

Replicas of the call state can be added by defining multiple SIP data tier servers in each partition. Example 6–4 shows the datatier.xml configuration file used to define a system having two partitions with two servers replicas in each partition. Example 6–4 SIP Data Tier Configuration for Small Deployment ?xml version=1.0 encoding=UTF-8? data-tier xmlns=http:www.bea.comnswlcpwlss300