Configuring and Managing WebLogic SIP Server
|
 |
 |
|
 |
 |
Overview of WebLogic SIP Server Configuration and Management
The following sections provide an overview of how to configure and manage WebLogic SIP Server deployments:
- Shared Configuration Tasks for WebLogic SIP Server and WebLogic Server
- Engine and Data Tier Configuration Overview
- Startup Sequence for a WebLogic SIP Server Domain
- Methods and Tools for Performing Configuration Tasks
- Administration Server Best Practices
- Common Configuration Tasks
Shared Configuration Tasks for WebLogic SIP Server and WebLogic Server
WebLogic SIP Server 2.1 is based on the award-winning WebLogic Server 8.1 application server, and many system-level configuration tasks are the same for both products. This manual addresses only those system-level configuration tasks that are unique to WebLogic SIP Server 2.1, such as tasks related to network and security configuration and cluster configuration for the engine and data tiers.
HTTP server configuration and other basic configuration tasks such as server logging, startup, and shutdown, are addressed in the WebLogic Server 8.1 Documentation.
Engine and Data Tier Configuration Overview
The SIP Servlet container and call data replication features of WebLogic SIP Server are implemented in an Enterprise Application (EAR), named sipserver, that is deployed on WebLogic Server 8.1. The same sipserver application code is deployed to both engine and data tier instances of WebLogic SIP Server, but the XML configuration file(s) included in the sipserver application determine the role of each server instance. A server instance initiates data tier services only if the server name is designated as a data tier server in the datatier.xml configuration file. Servers that are not part of the data tier provide SIP Servlet container features, and container properties are configured based on entries in the sipserver.xml configuration file.
The sipserver EAR is deployed in exploded archive format, and is automatically copied to the top level of the domain directory when you create a domain using the Configuration Wizard (for example, c:\bea\user_projects\domains\mydomain\sipserver). Figure 2-1, sipserver Web Application Contents, on page 2-3 summarizes the basic structure of the sipserver application. Only one copy of the deployment files are maintained per domain, and changes to the configuration are made by modifying the configuration files contained in the sipserver application.
Warning: Never redeploy or undeploy the sipserver implementation application on a running server. Always use the SIP Servers node in the Administration Console or the WLST utility, as described in Configuring Engine Tier Container Properties, to make changes to a running WebLogic SIP Server deployment.
Figure 2-1 sipserver Web Application Contents
Configuration Implementation
The config Web Application in sipserver provides the logic for parsing the sipserver.xml and datatier.xml files and applying configuration changes, as well as the implementation of the Administration Console extensions for configuring SIP features. Because the sipserver.xml and datatier.xml configuration files are included within a Web Application, changing the configuration for a WebLogic SIP Server deployment involves modifying these files. Configuration changes to SIP Servlet container properties can be applied dynamically to a running server by using the Administration Console SIP Servers node or from the command line using the WLST utility. Configuration for data tier nodes cannot be changed dynamically, so you must reboot data tier servers in order to change the number of partitions or replicas.
A special MBean included in the SIP Server implementation, ConfigManagerRuntimeMBean, handles locking and modifying configuration files in response to JMX commands, as well as applying configuration changes to running servers. Therefore, when you edit a WebLogic SIP Server configuration using the Administration Console or using JMX-based utilities, ConfigManagerRuntimeMBean manages updates to your configuration files transparently. See Configuring Engine Tier Container Properties. If you want to modify a configuration file outside of JMX, you must do so while WebLogic SIP Server is shut down. See Engine Tier Configuration Reference (sipserver.xml) and Data Tier Configuration Reference (datatier.xml).
Startup Sequence for a WebLogic SIP Server Domain
Note: WebLogic SIP Server start scripts use default values for many JVM parameters that affect performance. For example, JVM garbage collection and heap size parameters may be omitted, or may use values that are acceptable only for evaluation or development purposes. In a production system, you must rigorously profile your applications with different heap size and garbage collection settings in order to realize adequate performance. See Tuning JVM Garbage Collection for Production Deployments for suggestions about maximizing JVM performance in a production domain.
Warning: When you configure a domain with multiple engine and data tier servers, you must accurately synchronize all system clocks to a common time source (to within one or two milliseconds) in order for the SIP protocol stack to function properly. See Configuring NTP for Accurate SIP Timers in Configuring and Managing WebLogic SIP Server for more information.
Because a typical WebLogic SIP Server domain contains numerous engine and data tier servers, with dependencies between the different server types, you should generally follow this sequence when starting up a domain:
- Start the Administration Server for the domain. Start the Administration Server in order to provide the initial configuration to engine and data tier servers in the domain. The Administration Server can also be used to monitor the startup/shutdown status of each Managed Server. You generally start the Administration Server by using either the
startAdminServer.cmdscript installed with the Configuration Wizard, or a custom startup script. - Start data tier servers in each partition. The engine tier cannot function until servers in the data tier are available to manage call state data. Although all replicas in each partition need not be available to begin processing requests, at least one replica in each configured partition must be available in order to manage the concurrent call state. All replicas should be started and available before opening the system to production network traffic.
You generally start each data tier server by using either the
startManagedWebLogic.cmdscript installed with the Configuration Wizard, or a custom startup script.startManagedWebLogic.cmdrequires that you specify the name of the server to startup, as well as the URL of the Administration Server for the domain, as in:startManagedWebLogic.cmd datanode0-0 t3://adminhost:7001
Following the above startup sequence ensures that all Managed Servers use the latest SIP Servlet container and data tier configuration. This sequence also avoids engine tier error messages that are generated when servers in the data tier are unavailable.
Methods and Tools for Performing Configuration Tasks
WebLogic SIP Server provides several mechanisms for changing the configuration of the SIP Servlet container:
- Administration Console
- Upgrade Utility
- WebLogic Scripting Tool (WLST)
- Additional Configuration Methods
Administration Console
WebLogic SIP Server provides an Administration Console extension that allows you to modify and monitor SIP Servlet container and data tier configuration properties using a graphical user interface. The Administration Console for WebLogic SIP Server is similar to the console available in WebLogic Server 8.1. All SIP Server configuration and monitoring is available via the SIP Server node in the left pane. See Configuring Engine Tier Container Properties for more information about configuring the SIP Servlet container using the Administration Console.
Upgrade Utility
The WebLogic SIP Server upgrade utility, wlss.UpgradeConfig, helps you migrate an earlier WebLogic SIP Server configuration to a new WebLogic SIP Server 2.1 configuration. wlss.UpgradeConfig operates by taking an existing sipserver.xml configuration file and recreating the earlier configuration using the latest sipserver.xml schema. For more information about upgrading a configuration, see Upgrading a WebLogic SIP Server 2.0.x Configuration to Version 2.1.
WebLogic Scripting Tool (WLST)
The WebLogic Scripting Tool (WLST) enables you to perform interactive or automated (batch) configuration operations using a command-line interface. WLST is a JMX tool that can view or manipulate the MBeans available in a running WebLogic SIP Server domain. Configuring Engine Tier Container Properties provides instructions for modifying SIP Servlet container properties using WLST.
Additional Configuration Methods
Most WebLogic SIP Server configuration is performed using either the Administration Console or WLST. The methods described in the following sections may also be used for certain configuration tasks.
Editing Configuration Files
You may also edit sipserver.xml or datatier.xml by hand, following the respective schemas described in Engine Tier Configuration Reference (sipserver.xml) and Data Tier Configuration Reference (datatier.xml).
If you edit sipserver.xml by hand, you must manually reboot all servers to apply the configuration changes.
Warning: Never redeploy or undeploy the sipserver implementation application on a running server. Always use the SIP Servers node in the Administration Console or the WLST utility, as described in Configuring Engine Tier Container Properties, to make changes to a running WebLogic SIP Server deployment.
Data tier properties, such as the number of call state partitions and replicas, can never be changed while data tier server instances are running. If you edit datatier.xml, the changes are not applied until the data tier servers are rebooted.
Custom JMX Applications
WebLogic SIP Server properties are represented by JMX-compliant MBeans, and access to these MBeans and sipserver.xml is managed through the special runtime MBean, com.bea.wcp.sip.management.runtime.ConfigManagerRuntimeMBean. You can therefore program JMX application to configure SIP container properties using WebLogic SIP Server MBeans.
The general procedure for modifying WebLogic SIP Server MBean properties using JMX is described in Configuring Container Properties Using WLST (JMX) (WLST itself is a JMX-based application). For more information about the individual MBeans used to manage SIP container properties, see the WebLogic SIP Server Javadocs.
Administration Server Best Practices
The Administration Server in a WebLogic SIP Server 2.0.2 installation is required only for configuring, deploying, and monitoring J2EE services and applications; all SIP container configuration is performed using the container's sipserver.xml configuration file.
Note: If an Administration Server fails due to a hardware, software, or network problem, only management, deployment, and monitoring operations are affected. Managed Servers do not require the Administration Server for continuing operation; J2EE applications and SIP features running on Managed Server instances continue to function even if the Administration Server fails.
BEA recommends the following best practices for configuring Administration Server and Managed Server instances in your WebLogic SIP Server domain:
- Run the Administration Server instance on a dedicated machine. The Administration Server machine should have a memory capacity similar to Managed Server machines, although a single CPU is generally acceptable for administration purposes.
- Increase the threads available in the
weblogic.admin.RMIandweblogic.admin.HTTPexecute queues to match the number of managed servers in your system. - Configure all Managed Server instances to use Managed Server Independence. This feature allows the Managed Servers to restart even if the Administration Server is unreachable due to a network, hardware, or software failure. See Replicating a Domain's Configuration Files for Managed Server Independence in the WebLogic Server 8.1 documentation.
- Configure the Node Manager utility to automatically restart all Managed Servers in the WebLogic SIP Server domain. See Configuring, Starting, and Stopping Node Manager in the WebLogic Server 8.1 documentation.
Should an Administration Server instance or machine fail, remember that only configuration, deployment, and monitoring features are affected, but Managed Servers continue to operate and process client requests. Potential losses incurred due to an Administration Server failure include:
- Loss of in-progress management and deployment operations.
- Loss of ongoing logging functionality.
- Loss of SNMP trap generation for WebLogic Server instances (as opposed to WebLogic SIP Server instances). On Managed Servers, WebLogic SIP Server traps are generated even in the absence of the Administration Server.
To resume normal management activities, restart the failed Administration Server instance as soon as possible.
Adding threads to weblogic.admin.RMI and weblogic.admin.HTTP
You must increase the default size of the weblogic.admin.RMI and weblogic.admin.HTTP execute queues to ensure that an Administration Server can configure and monitor the large number of Managed Server instances deployed in a typical WebLogic SIP Server system. The number of threads in each queue should, match the number of deployed Managed Servers in both the engine and data tier clusters. By default, weblogic.admin.HTTP contains three threads and weblogic.admin.RMI contains two threads.
weblogic.admin.RMI and weblogic.admin.RMI are internal execute queues and are not displayed for configuration in the Administration Console. To add threads to the default queues, you must manually edit the config.xml file for your domain to specify the queue configuration. Listing 2-1 highlights the configuration entries required for managing 10 servers (10 threads in each queue). Note that
Listing 2-1 Increasing the Thread Count in Administration Server Execute Queues
<?xml version="1.0" encoding="UTF-8"?>
<Domain ConfigurationVersion="8.1.5.0" Name="my_domain">
<Cluster MulticastAddress="237.0.0.1" Name="BEA_ENGINE_TIER_CLUST"/>
<Cluster MulticastAddress="237.0.0.2" Name="BEA_DATA_TIER_CLUST"/>
<Server ListenAddress="admin_server_address" ListenPort="7001"
Name="my_admin_server" NativeIOEnabled="true"
ReliableDeliveryPolicy="RMDefaultPolicy" ServerVersion="8.1.5.0">
<SSL Enabled="false" HostnameVerificationIgnored="false"
IdentityAndTrustLocations="KeyStores" Name="my_admin_server"/>
<ExecuteQueue Name="weblogic.kernel.Default"/>
<ExecuteQueue Name="sip.tracing.domain" QueueLength="1024"
ThreadCount="1" ThreadsMaximum="1" ThreadsMinimum="1"/>
<ExecuteQueue Name="weblogic.admin.RMI" ThreadCount="10"/>
<ExecuteQueue Name="weblogic.admin.HTTP" ThreadCount="10"/>
</Server>
Common Configuration Tasks
General administration and maintenance of WebLogic SIP Server requires that you manage both WebLogic Server configuration properties and WebLogic SIP Server container properties. These common configuration tasks are summarized in Table 2-1.
Table 2-1 Common WebLogic SIP Server Configuration Tasks
