| Oracle® Communications Converged Application Server Administration Guide Release 5.0 Part Number E17647-03 |
|
|
View PDF |
| Oracle® Communications Converged Application Server Administration Guide Release 5.0 Part Number E17647-03 |
|
|
View PDF |
This chapter describes how to configure Oracle Communications Converged Application Server instances that make up the SIP data tier cluster of a deployment:
Best Practices for Configuring and Managing SIP Data Tier Servers
Example SIP Data Tier Configurations and Configuration Files
The 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 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 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 Chapter 31, "SIP Data Tier Configuration Reference (datatier.xml)" for complete information about the XML Schema and its 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.
To view and configure the current SIP data tier configuration in the Administration Console, click the SipServer node, click the Configuration tab, and then click the Data Tier tab. The SIP data tier configuration page is shown in the following figure.
Adding replicas can increase reliability for the system as a whole, however, 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.
Converged Application Server automatically divides the call state evenly over all configured partitions.
The sections that follow describe some common 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. Example 3-1 shows a SIP data tier configuration for a single-server deployment.
Example 3-1 SIP Data Tier Configuration for Small 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, define a second server-name entry in the same partition. For example, the datatier.xml configuration file shown in Example 3-2 recreates a two-replica configuration.
Example 3-2 SIP Data Tier Configuration for Small Deployment with Replication
<?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 Example 3-3.
Example 3-3 Two-Partition SIP Data Tier 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>
</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. Example 3-4 shows the datatier.xml configuration file used to define a system having two partitions with two servers (replicas) in each partition.
Example 3-4 SIP Data Tier Configuration for Small Deployment
<?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, ReplicaRuntimeMBean, provides valuable information about the current state and configuration of the SIP data tier. See the Converged Application Server JavaDocs for a description of the attributes provided in this MBean.
Many of the attributes can be viewed in the Administration Console by navigating to the SipServer node, clicking the Monitoring tab, and then clicking the Data Tier Information tab, as shown in the following figure.
Example 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 (following the example) describes the MBean services in more detail.
Example 3-5 Displaying ReplicaRuntimeMBean Attributes
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
Table 3-1 ReplicaRuntimeMBean Method and Attribute Summary
| Method/Attribute | Description |
|---|---|
|
|
Records the entire state of the selected SIP data tier server instance to the Converged Application Server log file. You may want to use the |
|
|
Provides statistics about call state data replicated from a remote geographical site. |
|
|
Provides statistics about call state data replicated to a remote geographical site. |
|
|
The total number of bytes received by this SIP data tier server. Bytes are received as servers in the engine tier provide call state data to be stored. |
|
|
The total number of bytes sent from this SIP data tier server. Bytes are sent to engine tier servers when requested to provide the stored call state. |
|
|
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 total number of stored call state keys for which this server has data. This attribute may be lower than the |
|
|
The total number of call state keys that must still be recovered from other replicas in the partition. A SIP data tier server may recover keys when it has been taken offline for maintenance and is then restarted to join the partition. |
|
|
The highest total number of call state keys that have been managed by this server since the server was started. |
|
|
The highest total number of bytes occupied by call state data that this server has managed since the server was started. |
|
|
The number of call data keys that are stored on the replica. |
|
|
The numerical partition ID (from 0 to 7) of this server's partition. |
|
|
The name of this server's partition. |
|
|
The numerical replica ID (from 0 to 2) of this server's replica. |
|
|
The name of this server's replica. |
|
|
The names of other Converged Application Server instances that are participating in the partition. |
|
|
The current state of the replica. SIP data tier servers can have one of three statuses:
|
|
|
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. Note: Engine tier servers periodically check with SIP data tier instances to determine if timers associated with a call have expired. In order for SIP timers to function properly, all engine tier servers must actively synchronize their system clocks to a common time source. Oracle recommends using a Network Time Protocol (NTP) client or daemon on each engine tier instance and synchronizing to a selected NTP server. See "Configuring Timer Processing". |
|
|
The total number of bytes consumed by the call state managed in this server. |
|
 Copyright © 2005, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|