|
|
This chapter describes upgrading Oracle Communications Services Gatekeeper 4.0/4.1 to Oracle Communications Services Gatekeeper 4.1.1
An Oracle Communications Services Gatekeeper 4.0/4.1 installation can be upgraded to Oracle Communications Services Gatekeeper 4.1.1 without shutting down the entire cluster or domain, which leads to no service interruption for applications using Oracle Communications Services Gatekeeper. The process is known as a Rolling Upgrade and is a WebLogic Server feature.
The process is based on a rolling scheme, where each server in the domain, one at the time, is stopped, upgraded to the new version, and then started. This process upgrades the WebLogic Server and the Oracle Communications Services Gatekeeper Core services, but leaves all communication services as before the upgrade.
When all servers have been upgraded, the communication services in use need to be upgraded. This is done using in-production redeployment, which is a WebLogic Server feature that enables the communication services to be upgraded without any traffic interruption.
It is strongly recommended that any configuration data be backed up prior to the upgrade.
The following limitations applies for the upgrade:
(Running database migration scripts is not necessary between 4.1 to 4.1.1.)
The upgrade process is divided into a set of sub-steps, see below:
Step 2: Upgrade the Communication Services
Step 3: Configure New Features
Step 4: Post Upgrade Procedure
Below is a description of the upgrade process for the servers. All steps must be performed on all servers, unless stated otherwise. The first server to upgrade must be the Administration Server.
This step is not necessary if you are moving from 4.1 to 4.1.1.
When all servers have been upgraded, the Communication Services must be upgraded, see Upgrade Communication Services and Interceptors.
If the new SIP-type Communication Services are to be used, the co-located Oracle Converged Application Server must be used.
Oracle Communications Services Gatekeeper 4.1 has a set of new features that must be manually installed and configured when upgrading. Note that it is only necessary to perform these steps if you are using this new functionality.
This step is not necessary if you are upgrading from 4.1 to 4.1.1.
When all servers have been upgraded, two new singleton services must be added and new CDR, EDR, and alarm definitions must added.
Follow the steps below to perform the post-upgrade procedures:
Clusters<Network Tier cluster>. Choose the Singleton Services tab.
In the Name field, enter BudgetEnforcementProxy
In the Class Name field, enter com.bea.wlcp.wlng.core.budget.BudgetEnforcementSingletonService
| Note: | If you are upgrading from 4.1 to 4.1.1, you do not need to complete d or e. |
In the Name field, enter GeoStorageProxy
In the Class Name field, enter com.bea.wlcp.wlng.geostorage.GeoStorageSingletonService
Using the Administration console, delete the BudgetEnforcementProxy singleton service. Starting in the Domain Structure pane, choose EnvironmentClusters<Network Tier cluster>. Choose the Singleton Services tab. Check the check-box BudgetEnforcementProxy and click Delete.
Some aspects of the way Oracle Communications Services Gatekeeper stores information in the database have changed with this release. You must run a set of migration scripts to upgrade your current data to Service Gatekeeper 4.0 formats.
This step is not necessary for upgrades from 4.1 to 4.1.1.
These scripts are located in the migration.zip file, which is found in <$BEA_HOME for OCSG 4.1>/wlserver_10.3/common/templates/scripts/
| Note: | The database scripts for MySQL (migrate_mysql.txt) and Oracle Database (migrate_oracle.txt) must be updated. Change from:UPDATE wlng_slas set sla_scope = 'sp_node' where sla_type='service_provider';to:UPDATE wlng_slas set sla_scope = 'sp' where sla_type='service_provider_node'; |
migration directory under the scripts directory. migration.zip file into the migration directory.db_migration.sh <DB TYPE [oracle | mysql]> <DB HOST> <DB NAME | ORACLE SERVICE NAME> <DB USERID> <PASSWORD>
Stop the server gracefully so all in-flight requests are processed before the shutdown start.
For information on how to stop a server using the administration console, see section Shutdown servers in a cluster in the Administration Console Online Help at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/ConsoleHelp/core/index.html.
For information about using the Graceful Shutdown command, see shutdown in WebLogic Scripting Tool at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/config_scripting/index.html.
You must shut the server down before starting to upgrade it.
Follow the steps below to upgrade the server:
Install it under a directory different from the $BEA_HOME directory used for your previous Oracle Communications Services Gatekeeper, whether it is 4.0 or 4.1. Do not configure the domain. The domain configuration used in your previous Oracle Communications Services Gatekeeper installation will be used.
On Windows: run the script $BEA_HOME_411\wlserver_10.3\server\bin\setWLSEnv.cmd
On UNIX: source the script $BEA_HOME_411/wlserver_10.3/server/bin/setWLSEnv.sh
$BEA_HOME_411 refers to the $BEA_HOME directory for Oracle Communications Services Gatekeeper 4.1.1
$BEA_HOME_411/wlserver_10.3/common/templates/scripts/upgrade and execute the target dist in the ant script. The ant script takes the following arguments:-Ddomain40.home, the $DOMAIN_HOME directory used in your previous Oracle Communications Services Gatekeeper installation, either 4.0 or 4.1.
-Dbea40.home, the $BEA_HOME directory used in your previous Oracle Communications Services Gatekeeper installation, either 4.0 or 4.1.
-Dbea41.home, the $BEA_HOME directory used in your new Oracle Communications Services Gatekeeper 4.1.1 installation.
-Dwlsold.home, the $WLS_HOME directory used in your previous Oracle Communications Services Gatekeeper installation, either 4.0 or 4.1.
-Dwlsnew.home, the $WLS_HOME directory used in your new Oracle Communications Services Gatekeeper 4.1.1 installation.
-Docsg.home, the $OCSG_HOME directory used in your new Oracle Communications Services Gatekeeper 4.1.1 installation.
-Dserver.name, the server name.
Example: (for 4.0 to 4.1/4.1.1):
ant dist -Ddomain40.home=/usr/local/ocsg-install/user_projects/domains/ocsg-domain
-Dbea40.home=/usr/local/ocsg40-install -Dbea41.home=/usr/local/ocsg41-install
-Dwlsold.home=/usr/local/ocsg40-install/wlserver_10.3
-Dwlsnew.home=/usr/local/ocsg41-install/wlserver_10.3
-Docsg.home=/usr/local/ocsg41-install/ocsg_4.1
-Dserver.name=AdminServer
Example: (for 4.1.0 to /4.1.1):
ant dist -Ddomain40.home=/usr/local/ocsg-install/user_projects/domains/ocsg-domain
-Dbea40.home=/usr/local/ocsg410-install -Dbea41.home=/usr/local/ocsg411-install
-Dwlsold.home= /usr/local/ocsg410-install/wlserver_10.3
-Dwlsnew.home=/usr/local/ocsg411-install/wlserver_10.3
-Docsg.home=/usr/local/ocsg411-install/ocsg_4.1
-Dserver.name=AdminServer
If the default installation directories were used, only these arguments need to be defined: Ddomain40.home, -Dbea40.home, -Dbea41.home, Dserver.name.
This step is not necessary for upgrade from 4.1 to 4.1.1.
This step is not necessary for upgrade from 4.1 to 4.1.1.
$DOMAIN_HOME/bin. $BEA_HOME_41/jdk160_05 (SUN) or $BEA_HOME_41/jrockit_160_05 (JRockit). Verify that the JDK you are using is installed in the appropriate directory. If the generic UNIX installer is used, the JDK is not provided so this must be installed. If generic installer was used to install Oracle Communications Services Gatekeeper, make sure to set the JAVA_HOME, defined in $DOMAIN_HOME/bin/setDomainEnv.sh to the right path in the file system.
| Note: | The infrastructure for the RESTful Service Facades needs to be deployed before upgrading the Communications Services. See Using RESTFul Service Facades. |
When the upgraded Oracle Communications Services Gatekeeper domain has been started, each Communication Service needs to be upgraded. This is done using the hitless upgrade procedure.
Refer to Hitless Upgrade Using Production Redeployment in Oracle Communications Services Gatekeeper System Administrator’s Guide for directions on how to perform a hitless upgrade.
The EAR names for each communication service and the JAR names for the network protocol plug-in are found under the heading “Properties for <Communication service>” in the section of Oracle Communications Services Gatekeeper System Administrator’s Guide which describes the appropriate Communication Service. There are a new set of Communication Services provided with Oracle Communications Services Gatekeeper:
These must be deployed manually, as they are not deployed automatically during an upgrade. Refer to the individual sections for each of these Communication Services in Oracle Communications Services Gatekeeper System Administrator’s Guide for information on which EARs to deploy.
The Service Enablers for the SIP plug-ins have been updated to work with a co-located Oracle Converged Application Server. These must be redeployed, and cannot be upgraded using the hitless upgrade procedure. In order for the new SIP-type plug-ins to be functional, the steps involving upgrading the SIP Connectivity must be performed. Any subscriptions for notifications that have been registered by an application must be unregistered prior to the upgrade and then re-registered after the upgrade since there are incompatible changes to the store. Exceptions will be thrown if old data is accessed after the upgrade.
The Service Enabler for Parlay X 2.1/Extended Web Services Binary SMS/SMPP does not support to be hitlessly upgraded from the version that was a part of Oracle Communications Services Network Gatekeeper 4.0 to the version included in Oracle Communications Services Network Gatekeeper 4.0. The 4.0 version must be undeployed before the servers are upgraded and then the new version is deployed after the servers are upgraded.
The Service interceptors have also been updated. Deploy:
in the same manner as the Communication Services. The Service Interceptors are located in the directory $OCSG_HOME/applications, where $OCSG_HOME is the installation directory for Oracle Communications Services Gatekeeper 4.1.
A set of new features and components were added in Oracle Communications Services Gatekeeper 4.1. This section describes how to leverage these features.
Oracle Communications Services Gatekeeper used WebLogic SIP server to connect to the SIP network. A standalone SIP Server installation was used.
Oracle Communications Services Gatekeeper 4.1 has Oracle Converged Application Server co-located with the Network Tier server.
Follow the instructions below to use Converged Application Server for SIP Communication Services.
| Note: | Make sure that the modifications are done only on the Administration server and it is shut down while doing edits to config.xml. |
<server>
<name>WLNG_NT1</name>
<max-message-size>20000000</max-message-size>
<log>
<name>WLNG_NT1</name>
<log-file-severity>Info</log-file-severity>
<memory-buffer-severity>Info</memory-buffer-severity>
</log>
<machine>NT1</machine>
<listen-port>8001</listen-port>
<cluster>WLNG_NT_Cluster</cluster>
<web-server>
<name>WLNG_NT1</name>
<web-server-log>
<logging-enabled>false</logging-enabled>
</web-server-log>
</web-server>
<listen-address>host-nt1.bea.com</listen-address> <network-access-point> <name>sipchannel</name> <protocol>sip</protocol> <listen-port>5060</listen-port> <public-port>5060</public-port> <http-enabled-for-this-protocol>false</http-enabled-for-this-protocol> <tunneling-enabled>false</tunneling-enabled> <outbound-enabled>true</outbound-enabled> <enabled>true</enabled> <two-way-ssl-enabled>false</two-way-ssl-enabled> <client-certificate-enforced>false</client-certificate-enforced> </network-access-point> <network-access-point> <name>sips</name> <protocol>sips</protocol> <listen-port>5061</listen-port> <public-port>5061</public-port> <http-enabled-for-this-protocol>false</http-enabled-for-this-protocol> <tunneling-enabled>false</tunneling-enabled> <outbound-enabled>true</outbound-enabled> <enabled>true</enabled> <two-way-ssl-enabled>false</two-way-ssl-enabled> <client-certificate-enforced>false</client-certificate-enforced> </network-access-point><jta-migratable-target>
<name>WLNG_NT1</name>
<user-preferred-server>WLNG_NT1</user-preferred-server>
<cluster>WLNG_NT_Cluster</cluster>
</jta-migratable-target>
<managed-server-independence-enabled>false</managed-server-independence-enabled>
</server>
<server>
<name>WLNG_NT2</name>
<max-message-size>20000000</max-message-size>
<log>
<log-file-severity>Info</log-file-severity>
<memory-buffer-severity>Info</memory-buffer-severity>
</log>
<machine>NT2</machine>
<listen-port>8001</listen-port>
<cluster>WLNG_NT_Cluster</cluster>
<web-server>
<web-server-log>
<logging-enabled>false</logging-enabled>
</web-server-log>
</web-server>
<listen-address>host-nt2.bea.com</listen-address> <network-access-point> <name>sipchannel</name> <protocol>sip</protocol> <listen-port>5070</listen-port> <public-port>5070</public-port> <http-enabled-for-this-protocol>false</http-enabled-for-this-protocol> <tunneling-enabled>false</tunneling-enabled> <outbound-enabled>true</outbound-enabled> <enabled>true</enabled> <two-way-ssl-enabled>false</two-way-ssl-enabled> <client-certificate-enforced>false</client-certificate-enforced> </network-access-point> <network-access-point> <name>sips</name> <protocol>sips</protocol> <listen-port>5071</listen-port> <public-port>5071</public-port> <http-enabled-for-this-protocol>false</http-enabled-for-this-protocol> <tunneling-enabled>false</tunneling-enabled> <outbound-enabled>true</outbound-enabled> <enabled>true</enabled> <two-way-ssl-enabled>false</two-way-ssl-enabled> <client-certificate-enforced>false</client-certificate-enforced> </network-access-point><jta-migratable-target>
<user-preferred-server>WLNG_NT2</user-preferred-server>
<cluster>WLNG_NT_Cluster</cluster>
</jta-migratable-target>
<managed-server-independence-enabled>false</managed-server-independence-enabled>
</server>
<custom-resource>
<name>sipserver</name>
<target>WLNG_NT_Cluster</target>
<descriptor-file-name>custom/sipserver.xml</descriptor-file-name>
<resource-class>com.bea.wcp.sip.management.descriptor.resource.SipServerResource</resource-class>
<descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.SipServerBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>datatier</name>
<target>WLNG_NT_Cluster</target>
<descriptor-file-name>custom/datatier.xml</descriptor-file-name>
<resource-class>com.bea.wcp.sip.management.descriptor.resource.DataTierResource</resource-class>
<descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.DataTierBean</descriptor-bean-class>
</custom-resource>
<custom-resource>
<name>approuter</name>
<target>AdminServer</target>
<descriptor-file-name>custom/approuter.xml</descriptor-file-name>
<resource-class>com.bea.wcp.sip.management.descriptor.resource.AppRouterResource</resource-class>
<descriptor-bean-class>com.bea.wcp.sip.management.descriptor.beans.SipServerBean</descriptor-bean-class>
</custom-resource>
RESTful Service Facades are new to Oracle Communications Services Gatekeeper 4.1.
Follow the instructions below to use the RESTful service Facades.
| Note: | Make sure that the modifications are done only on the Administration server and it is shut down while doing edits to config.xml. |
<security-dd-model>DDOnly</security-dd-model>See Oracle WebLogic Server Deploying Applications to WebLogic Server at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/deployment/ for a description of the different deployment options.
| Note: | If your installation uses multiple AT clusters, only one AT cluster can host RESTful facades. See the ”Deployment Model for Communications Services” chapter, the “Deployment of SOAP and RESTful Facades on Multiple AT Clusters” section in the System Administrator’s Guide for more information. |
<jms-server>
<name>JMSServer-AT1</name>
<target>WLNG_AT1</target>
</jms-server>
<jms-server>
<name>JMSServer-AT2</name>
<target>WLNG_AT2</target>
</jms-server>
<jms-system-resource>
<name>WLNG_ATJMSResource</name>
<target>WLNG_AT_Cluster</target>
<descriptor-file-name>jms/wlng_at-jms.xml</descriptor-file-name>
</jms-system-resource>
SOA Service Facades are new to Oracle Communications Services Gatekeeper 4.1. For information on how to install the SOA Service Facades, see Installation of SOA Facades.
Oracle Communications Services Gatekeeper 4.1 has introduced a set of new and changed EDR, CDR, and alarm definitions.
Refer to each of the following sections for a list of the changes:
The list contains IDs of the entries. Use the EDR configuration file wlng-edr.xml, and copy the definitions into the EDR Configuration page in the Administration console.
The EDR configuration file is located in the directory config/custom in the JAR file $BEA_HOME_41/wlserver_10.3/common/templates/domains/ocsg-domain.jar
Below is a list of changed and new EDRs. Copy the EDR definitions, not just the ID. These changes reflect 4.1 unless they are specifically marked 4.1.1.
Below is a list of changed and new CDR definitions.
Locate the CDR definition for the new CDR based on the method name and the package name in the EDR definition file. For new CDRs, copy the whole entry. If it is an existing and changed CDR, edit the listing. Example:
<name>void callConnected</name>
<class>com.bea.wlcp.wlng.plugin.tpc.sip.south.SipContextMapper</class>
Below is a list of changed and new alarms. Copy the new alarm definitions, not just the ID.
|