> Configuration Guide > Configuring Data Tier Partitions and Replicas

Configuration Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Configuring Data Tier Partitions and Replicas

The following sections describe how to configure WebLogic SIP Server instances that make up the data tier cluster of a deployment:

 

Overview of Data Tier Configuration

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.

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.

datatier.xml Configuration File

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.

Configuration Requirements and Restrictions

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.

Figure 3-1 Administration Console Display of Data Tier Configuration (Read-Only)

Administration Console Display of Data Tier Configuration (Read-Only)

 

Best Practices for Configuring and Managing 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.

Data tier servers can have one of three different statuses:

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.

 

Example Data Tier Configurations and Configuration Files

The sections that follow describe some common WebLogic SIP Server installations that utilize a separate data tier.

Data Tier with One Partition

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.

Listing 3-1 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, simply define a second server-name entry in the same partition. For example, the datatier.xml configuration file shown in Listing 3-2 creates a two-replica configuration.

Listing 3-2 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>

Data Tier with Two Partitions

Multiple partitions can be easily created by defining multiple partition entries in datatier.xml, as shown in Listing 3-3.

Listing 3-3 Two-Partition 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>

Data Tier with Two Partitions and Two Replicas

Replicas of the call state can be added by defining multiple data tier servers in each partition. Listing 3-4 shows the datatier.xml configuration file used to configure a system with two partitions and two servers (replicas) in each partition.

Listing 3-4 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>

 

Monitoring and Troubleshooting Data Tier Servers

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.

Figure 3-2 Data Tier Monitoring in the Administration Console

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.

Listing 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
dumpState()
Records the entire state of the selected data tier server instance to the WebLogic SIP Server log file. You may want to use the dumpState() method to provide additional diagnostic information to a Technical Support representative in the event of a problem. 
BackupStoreInboundStatistics
Provides statistics about call state data replicated from a remote geographical site. 
BackupStoreOutboundStatistics
Provides statistics about call state data replicated to a remote geographical site.
BytesReceived
The total number of bytes received by this data tier server. Bytes are received as servers in the engine tier provide call state data to be stored.
BytesSent
The total number of bytes sent from this data tier server. Bytes are sent to engine tier servers when requested to provide the stored call state.
CurrentViewId
The current view ID. Each time the layout of the data tier changes, the view ID is incremented. For example, as multiple servers in a data tier cluster are started for the first time, the view ID is incremented when each server begins participating in the data tier. Similarly, the view is incremented if a server is removed from the data tier, either intentionally or due to a failure.
DataItemCount
The total number of stored call state keys for which this server has data. This attribute may be lower than the KeyCount attribute if the server is currently recovering data.
DataItemsToRecover
The total number of call state keys that must still be recovered from other replicas in the partition. A data tier server may recover keys when it has been taken offline for maintenance and is then restarted to join the partition.
HighKeyCount
The highest total number of call state keys that have been managed by this server since the server was started.
HighTotalBytes
The highest total number of bytes occupied by call state data that this server has managed since the server was started.
KeyCount
The number of call data keys that are stored on the replica.
PartitionId
The numerical partition ID (from 0 to 7) of this server’s partition.
PartitionName
The name of this server’s partition.
ReplicaId
The numerical replica ID (from 0 to 2) of this server’s replica.
ReplicaName
The name of this server’s replica.
ReplicaServersInCurrentView
The names of other WebLogic SIP Server instances that are participating in the partition.
State
The current state of the replica. 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.
TimerQueueSize
The current number of timers queued on the 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 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. BEA recommends using a Network Time Protocol (NTP) client or daemon on each engine tier instance and synchronizing to a selected NTP server.
TotalBytes
The total number of bytes consumed by the call state managed in this server.


  Back to Top       Previous  Next