|
|
The following sections describe how to configure WebLogic SIP Server instances that make up the data tier cluster of a deployment:
The WebLogic SIP Server data tier is a cluster of server instances that manages the application call state for concurrent SIP calls. The 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 data tier cluster is arranged into one or more partitions. A partition consists of one or more data tier server instances that manage the same portion of concurrent call state data. In a single-server WebLogic SIP Server installation, or in a two-server installation where one server resides in the engine tier and one resides in the 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 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. See Capacity Planning for WebLogic SIP Server Deployments for more information.
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. BEA 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 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 WebLogic SIP Server 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 data tier configurations. See also
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 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 data tier configuration while replicas or engine tier nodes are running. You must restart servers in the domain in order to change data tier membership or reconfigure partitions or replicas.
You can view the current 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.
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 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.
WebLogic SIP Server automatically divides the call state evenly over all configured partitions.
The sections that follow describe some common WebLogic SIP Server installations that utilize a separate data tier.
A single-partition, single-server data tier represents the simplest data tier configuration. Listing 3-1 shows a 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 the two-replica configuration shown in
Figure 3-3, Small Deployment with High Availability, on page 3-8.
<?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 data tier servers in each partition.
Figure 3-4, Medium-Sized Deployment, on page 3-9 shows a system having two partitions with two servers (replicas) in each partition. Listing 3-4 shows the datatier.xml configuration file used to define this data tier.
<?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 data tier. See the
WebLogic SIP 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 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 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
|