|
|
The following sections describe how to configure Oracle Communications Converged Application Server instances that make up the SIP data tier cluster of a deployment:
The Oracle Communications Converged Application Server SIP data tier is a cluster of server instances that manages the application call state for concurrent SIP calls. The SIP data tier may manage a single copy of the call state or multiple copies as needed to ensure that call state data is not lost if a server machine fails or network connections are interrupted.
The SIP data tier cluster is arranged into one or more partitions. A partition consists of one or more SIP data tier server instances that manage the same portion of concurrent call state data. In a single-server Oracle Communications Converged Application Server installation, or in a two-server installation where one server resides in the engine tier and one resides in the SIP data tier, all call state data is maintained in a single partition. Multiple partitions are required when the size of the concurrent call state exceeds the maximum size that can be managed by a single server instance. When more than one partition is used, the concurrent call state is split among the partitions, and each partition manages an separate portion of the data. For example, with a two-partition SIP data tier, one partition manages the call state for half of the concurrent calls (for example, calls A through M) while the second partition manages the remaining calls (N through Z).
In most cases, the maximum call state size that can be managed by an individual server corresponds to the Java Virtual Machine limit of approximately 1.6GB per server.
Additional servers can be added within the same partition to manage copies of the call state data. When multiple servers are members of the same partition, each server manages a copy of the same portion of the call data, referred to as a replica of the call state. If a server in a partition fails or cannot be contacted due to a network failure, another replica in the partition supplies the call state data to the engine tier. Oracle recommends configuring two servers in each partition for production installations, to guard against machine or network failures. A partition can have a maximum of three replicas for providing additional redundancy.
The datatier.xml configuration file, located in the config/custom subdirectory of the domain directory, identifies SIP data tier servers and also defines the partitions and replicas used to manage the call state. If a server’s name is present in datatier.xml, that server loads Oracle Communications Converged Application Server SIP data tier functionality at boot time. (Server names that do not appear in datatier.xml act as engine tier nodes, and instead provide SIP Servlet container functionality configured by the sipserver.xml configuration file.)
The sections that follow show examples of the datatier.xml contents for common SIP data tier configurations. See also
SIP Data Tier Configuration Reference (datatier.xml) in the Configuration Reference Manual for full information about the XML Schema and elements.
All servers that participate in the SIP data tier should be members of the same WebLogic Server cluster. The cluster configuration enables each server to monitor the status of other servers. Using a cluster also enables you to easily target the sipserver and datatier custom resources to all servers for deployment.
For high reliability, you can configure up to three replicas within a partition.
You cannot change the SIP data tier configuration while replicas or engine tier nodes are running. You must restart servers in the domain in order to change SIP data tier membership or reconfigure partitions or replicas.
You can view the current SIP data tier configuration using the Configuration->Data Tier page (SipServer node) of the Administration Console, as shown in Figure 3-1.
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 Communications Converged Application Server automatically divides the call state evenly over all configured partitions.
The sections that follow describe some common Oracle Communications Converged Application Server installations that utilize a separate SIP data tier.
A single-partition, single-server SIP data tier represents the simplest data tier configuration. Listing 3-1 shows a SIP data tier configuration for a single-server deployment.
<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>part-1</name>
<server-name>replica1</server-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 Listing 3-2 recreates a two-replica configuration.
<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
<server-name>DataNode0-1</server-name>
</partition>
</data-tier>
Multiple partitions can be easily created by defining multiple partition entries in datatier.xml, as shown in Listing 3-3.
<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
</partition>
<partition>
<name>Partition1</name>
<server-name>DataNode1-0</server-name>
</partition>
</data-tier>
Replicas of the call state can be added by defining multiple SIP data tier servers in each partition. Listing 3-4 shows the datatier.xml configuration file used to define a system having two partitions with two servers (replicas) in each partition.
<?xml version="1.0" encoding="UTF-8"?>
<data-tier xmlns="http://www.bea.com/ns/wlcp/wlss/300">
<partition>
<name>Partition0</name>
<server-name>DataNode0-0</server-name>
<server-name>DataNode0-1</server-name>
</partition>
<partition>
<name>Partition1</name>
<server-name>DataNode1-0</server-name>
<server-name>DataNode1-1</server-name>
</partition>
</data-tier>
A runtime MBean, com.bea.wcp.sip.management.runtime.ReplicaRuntimeMBean, provides valuable information about the current state and configuration of the SIP data tier. See the
Oracle Communications Converged Application Server JavaDocs for a description of the attributes provided in this MBean.
Many of these attributes can be viewed using the SIP Servers Monitoring->Data Tier Information tab in the Administration Console, as shown in SIP Data Tier Monitoring in the Administration Console.
Listing 3-5 shows a simple WLST session that queries the current attributes of a single Managed Server instance in a SIP data tier partition. Table 3-1, ReplicaRuntimeMBean Method and Attribute Summary, on page 3-8 describes the MBean services in more detail.
connect(‘weblogic’,’weblogic’,’t3://datahost1:7001’)custom()cd('com.bea')cd('com.bea:ServerRuntime=replica1,Name=replica1,Type=ReplicaRuntime')ls()-rw- BackupStoreInboundStatistics null
-rw- BackupStoreOutboundStatistics null
-rw- BytesReceived 0
-rw- BytesSent 0
-rw- CurrentViewId 2
-rw- DataItemCount 0
-rw- DataItemsToRecover 0
-rw- DatabaseStoreStatistics null
-rw- HighKeyCount 0
-rw- HighTotalBytes 0
-rw- KeyCount 0
-rw- Name replica1
-rw- Parent com.bea:Name=replica1,Type=S
erverRuntime
-rw- PartitionId 0
-rw- PartitionName part-1
-rw- ReplicaId 0
-rw- ReplicaName replica1
-rw- ReplicaServersInCurrentView java.lang.String[replica1, replica2]
-rw- ReplicasInCurrentView [I@75378c
-rw- State ONLINE
-rw- TimerQueueSize 0
-rw- TotalBytes 0
-rw- Type ReplicaRuntime
BackupStoreInboundStatistics |
|||
BackupStoreOutboundStatistics |
|||
The current view ID. Each time the layout of the SIP data tier changes, the view ID is incremented. For example, as multiple servers in a SIP data tier cluster are started for the first time, the view ID is incremented when each server begins participating in the SIP data tier. Similarly, the view is incremented if a server is removed from the SIP data tier, either intentionally or due to a failure.
|
|||
|
|||
The current number of timers queued on the SIP data tier server. This generally corresponds to the KeyCount value, but may be less if new call states are being added but their associated timers have not yet been queued.
|
|||
|