Important Terminology
We recommend that, before proceeding, you familiarize yourself with the following terminology:
Upgrade:To update WebLogic products from a previous release or service pack to a more recent one. This process may include updating an existing application or domain configuration to run in a more recent version of WebLogic Server.
Migrate:To move an application or domain configuration from a third-party product to an Oracle product.
Interoperability:(1) The ability of an application deployed in one release or service pack to communicate with another application that is deployed in a different release or service pack. (2) The ability of Oracle product components to communicate with third-party software using standard protocols.
Compatibility:The capability of an application built using one release or service pack to run in another release or service pack, regardless of whether the application was rebuilt.
Supported Configurations recommendations for WebLogic versions
Application Server versions
WebLogic Server 12c Release 2 (12.1.2) - July 11, 2013[1]
WebLogic Server 12c Release 1 (12.1.1) - Dec 1, 2011[2]
WebLogic Server 11gR1 PS5 (10.3.6) - February 26, 2012[3]
WebLogic Server 11gR1 PS4 (10.3.5) - May 16, 2011[4]
WebLogic Server 11gR1 PS3 (10.3.4) - January 15, 2011
WebLogic Server 11gR1 PS2 (10.3.3) - April 2010[5]
WebLogic Server 11gR1 PS1 (10.3.2) - November 2009
WebLogic Server 11g (10.3.1) - July 2009
WebLogic Server 10.3 - August 2008[6]
WebLogic Server 10.0 - March 2007[7]
WebLogic Server 9.2
WebLogic Server 9.1
WebLogic Server 9.0 - November 2006[8]
WebLogic Server 8.1-bea - July 2003[8]
WebLogic Server 7.0 - June 2002[9]
WebLogic Server 6.1
WebLogic Server 6.0 - file date March 2001 on an old CD[10]
WebLogic Server 5.1 (code name: Denali) First version supporting hot deployment for applications (via command line)
WebLogic Server 4.0
WebLogic Tengah 3.1 - June 1998[11]
WebLogic Tengah 3.0.1 - March 1998[12]
WebLogic Tengah 3.0 - January 1998[13]
WebLogic Tengah - November 1997[14]
Recommendations
================
We recommend that, before proceeding, you familiarize yourself with the following terminology:
Upgrade:To update WebLogic products from a previous release or service pack to a more recent one. This process may include updating an existing application or domain configuration to run in a more recent version of WebLogic Server.
Migrate:To move an application or domain configuration from a third-party product to an Oracle product.
Interoperability:(1) The ability of an application deployed in one release or service pack to communicate with another application that is deployed in a different release or service pack. (2) The ability of Oracle product components to communicate with third-party software using standard protocols.
Compatibility:The capability of an application built using one release or service pack to run in another release or service pack, regardless of whether the application was rebuilt.
Supported Configurations recommendations for WebLogic versions
Application Server versions
WebLogic Server 12c Release 2 (12.1.2) - July 11, 2013[1]
WebLogic Server 12c Release 1 (12.1.1) - Dec 1, 2011[2]
WebLogic Server 11gR1 PS5 (10.3.6) - February 26, 2012[3]
WebLogic Server 11gR1 PS4 (10.3.5) - May 16, 2011[4]
WebLogic Server 11gR1 PS3 (10.3.4) - January 15, 2011
WebLogic Server 11gR1 PS2 (10.3.3) - April 2010[5]
WebLogic Server 11gR1 PS1 (10.3.2) - November 2009
WebLogic Server 11g (10.3.1) - July 2009
WebLogic Server 10.3 - August 2008[6]
WebLogic Server 10.0 - March 2007[7]
WebLogic Server 9.2
WebLogic Server 9.1
WebLogic Server 9.0 - November 2006[8]
WebLogic Server 8.1-bea - July 2003[8]
WebLogic Server 7.0 - June 2002[9]
WebLogic Server 6.1
WebLogic Server 6.0 - file date March 2001 on an old CD[10]
WebLogic Server 5.1 (code name: Denali) First version supporting hot deployment for applications (via command line)
WebLogic Server 4.0
WebLogic Tengah 3.1 - June 1998[11]
WebLogic Tengah 3.0.1 - March 1998[12]
WebLogic Tengah 3.0 - January 1998[13]
WebLogic Tengah - November 1997[14]
Recommendations
================
The table below lists major standards supported by WebLogic Server product version.
| Standard | ||||||
| Java | 1.3 | 1.4 | 5 | 5 | 6 (7 in 10.3.6+) | 7 |
| Java EE | 1.3 | 1.3 | 1.4 | 5 | 5 | 6 |
| Servlet | 1.2 | 2.3 | 2.4 | 2.5 | 2.5 | 3.0 |
| JSP | 1.2 | 1.2 | 2.0 | 2.1 | 2.1 | 2.2 |
| EJB | 2.0 | 2.0 | 2.1 | 3.0 | 3.0 | 3.1 |
| JDBC | 2.0 | 2.0 | 3.0 | 3.0 | 3.0 | 4.0 |
O.S JDK/ SDK DATABASE WEBSERVERS
8.1
HP-UX 11i V2 JDK 1.4.2.10 DB2 8.1 Apache 2.0 and higher
IBM-AIX v5.3 IBM SDK 1.4.2. Oracle 8.1.7 IIS 6.0 and higher
RedHat Linux 4.0 BEA JRockit 1.4.2_10 Oracle 9i (9.2.0) Iplanet 4.x
Sunsolaris 8,9 Sun Java 2 SDK 1.4.2_11 PointBase 4.4
Microsoft xp Sun Java 2 SDK 1.4.2_11 SQL Server 2000
Sybase 12.5
9.2
HP-UX 11i V2 JDK 1.4.2.10 DB2 9.5 Apache 2.2 and higher
IBM-AIX v5.3 IBM SDK 1.4.2. Oracle 8.1.7 IIS 6.0 and higher
RedHat Linux 4.0 BEA JRockit 1.4.2_10 Oracle 10.g,11g SunOne 6.1
Sunsolaris 8,9 Sun Java 2 SDK 1.4.2_11 PointBase 5.7
Microsoft xp Sun Java 2 SDK 1.4.2_11 SQL Server 2005
Sybase 15.0.x
Mysql 4.0
10.0
HP-UX 11i V2 JDK 1.4.2.10 DB2 9.5 Apache 2.2 and higher
IBM-AIX v5.3 IBM SDK 1.4.2. Oracle 8.1.7 IIS 6.0 and higher
RedHat Linux 4.0,5.0 BEA JRockit 1.4.2_10 Oracle 10.g,11g SunOne 6.1
Sunsolaris 8,9,10 Sun Java 2 SDK 1.4.2_11 PointBase 5.7
Windows 2008 Sun Java 2 SDK 1.4.2_11 SQL Server 2005
Sybase 15.0.x
Mysql 4.0
10.3.
HP-UX 11i V2,V3 JDK 1.4.2.10 DB2 9.5 Apache 2.2 and higher
IBM-AIX v6.1, IBM SDK 1.4.2. Oracle 8.1.7 IIS 6.0 and higher
RedHat Linux 5.0 BEA JRockit 1.4.2_10 Oracle 10.g,11g SunOne 6.1
Sunsolaris 9,10 Sun Java 2 SDK 1.4.2_11 PointBase 5.7
Windows 2008 Sun Java 2 SDK 1.4.2_11 SQL Server 2005
Sybase 15.0.x
Mysql 4.0
11g -10.3.3
HP-UX 11i V2 JDK 1.4.2.10 DB2 9.5 Apache 2.2 and higher
IBM-AIX v5 IBM SDK 1.4.2. Oracle 8.1.7 IIS 6.0 and higher
RedHat Linux 4.0 BEA JRockit 1.4.2_10 Oracle 10.g,11g SunOne 6.1
Sunsolaris 8,9 Sun Java 2 SDK 1.4.2_11 PointBase 5.7
Microsoft xp Sun Java 2 SDK 1.4.2_11 SQL Server 2005
Sybase 15.0.x
Mysql 4.0
12c-12.1.1
HP-UX 11i V2 JDK 1.4.2.10 DB2 9.5 Apache 2.2 and higher
IBM-AIX v5.3 IBM SDK 1.4.2. Oracle 8.1.7 IIS 6.0 and higher
RedHat Linux 4.0 BEA JRockit 1.4.2_10 Oracle 10.g,11g SunOne 6.1
Sunsolaris 8,9 Sun Java 2 SDK 1.4.2_11 PointBase 5.7
Microsoft xp Sun Java 2 SDK 1.4.2_11 SQL Server 2005
Sybase 15.0.x
Mysql 4.0
----------------------------------------------------------------------------------------------------------
Upgrade Procedures
When you upgrade to a newer release of WebLogic Server, in most cases you don't have to upgrade
the web applications you deploy. The latest release of WebLogic Server, 10.3.4, will work with all applications you created on WebLogic Server 7.0, 8.1, 9.x, 10.0, or any 10.3 release servers. However, you have to upgrade several components of the server:
1 Domains
2 Custom security provider
3 Node Manager
In addition, you need to ensure that any external resources WebLogic Server connects to, such as an Oracle database, for example, are compatible with the new release. The following sections briefly describe the upgrade procedures. Before you start the actual upgrade process, however, do the usual due diligence effort, such as verifying the supported configurations and the compatibility of the various software applications, as well as doing an inventory of your current WebLogic Server environment.
As with any upgrade of a server, back up your applications, shut down all running servers, and start by installing the new release of the Oracle WebLogic Server software.
When you upgrade to a newer release of WebLogic Server, in most cases you don't have to upgrade
the web applications you deploy. The latest release of WebLogic Server, 10.3.4, will work with all applications you created on WebLogic Server 7.0, 8.1, 9.x, 10.0, or any 10.3 release servers. However, you have to upgrade several components of the server:
1 Domains
2 Custom security provider
3 Node Manager
In addition, you need to ensure that any external resources WebLogic Server connects to, such as an Oracle database, for example, are compatible with the new release. The following sections briefly describe the upgrade procedures. Before you start the actual upgrade process, however, do the usual due diligence effort, such as verifying the supported configurations and the compatibility of the various software applications, as well as doing an inventory of your current WebLogic Server environment.
As with any upgrade of a server, back up your applications, shut down all running servers, and start by installing the new release of the Oracle WebLogic Server software.
Overview of the Upgrade Process
The process required to upgrade an application environment depends on the scope of the application. An application environment includes a WebLogic domain and any applications and application data associated with the domain. It may also include external resources, such as firewalls, load balancers, and LDAP servers. Figure 1-1 shows an example of a WebLogic application environment.
Table 1-1 lists the components of the WebLogic application environment shown in Figure 1-1 and the upgrade requirements for each.
| Component | Description | Upgrade Requirements |
| WebLogic domain | Includes the Administration Server (AS) and optionally one or more Managed Servers (for example, MS1, MS2, MS3, and MS4). The servers in a domain may span multiple machines. Furthermore, you can group Managed Servers into clusters to support load balancing and failover protection for critical applications. For more information about WebLogic domains, see "Understanding Oracle WebLogic domains" in Understanding Domain Configuration for Oracle WebLogic Server. | Upgrade the domain directory on each computer in the domain. |
| Custom security provider | Supports custom security requirements. For information about developing custom security providers, see Developing Security Providers for Oracle WebLogic Server. | Upgrade the custom security providers on each computer in the domain. |
| Node Manager | Provides high availability to Managed Servers. For more information about Node Manager, see "Node Manager Overview" in Node Manager Administrator's Guide for Oracle WebLogic Server. | Upgrade custom Node Manager on each computer in the domain. |
| Applications | Any Java EE applications, including Web applications, EJBs, and so on. Typically, applications are deployed to one or more Managed Servers in a domain. Depending on the deployment strategy, applications may reside locally on a computer or be accessible using a shared directory. In addition, external client applications may access the application environment from outside a firewall. | Most WebLogic Server applications can be run without modifications in the new WebLogic Server 10.3.6 application environment. For more information, see Interoperability and Compatibility with Previous Releases. |
| External resources | Software components, such as databases for storing domain and application data, load balancers, and firewalls. | Verify that all external resources are compatible with WebLogic Server 10.3.6. For more information, see "Supported Configurations" in What's New in Oracle WebLogic Server. |
The WebLogic Upgrade Wizard guides you through the steps required to upgrade a WebLogic domain that is compatible with WebLogic Server 8.1 or later such that it runs in a WebLogic Server 10.3.6 application environment. As part of the upgrade process, you must upgrade any custom security providers and Node Managers used in the domain.
You can also use the WebLogic Upgrade Wizard to upgrade to 10.3.6 a WebLogic domain that is compatible with WebLogic Server 9.x or 10.0, but this is optional. This type of domain runs under WebLogic Server 10.3.6 without modification.
You can step through the upgrade process interactively, using the graphical user interface (GUI), or "silently", by creating an upgrade script and running it. Silent Mode is supported for upgrading a WebLogic domain, security providers, and Node Manager.
Application environments that run with WebLogic Server 10.3.6 can interact with application environments built on WebLogic Server Version 8.1, 9.x, 10.0, or 10.3.
Most existing WebLogic Server applications can be run without modification in the new WebLogic Server 10.3.6 application environment. You should review the compatibility information described in Appendix B, "WebLogic Server 10.3.6 Compatibility with Previous Releases," to determine whether any feature changes affect the applications in your environment. If your application uses APIs that have been deprecated or removed, then you may encounter warnings or exceptions at run time (see "Deprecated Functionality (WebLogic Server 11g Release 1)" in What's New in Oracle WebLogic Server).
“ Whole server Migration”
Whole Server Migration is one of the key High Availability features within the WebLogic application
server. It can be used for automatic or manual migration of an entire WebLogic Server JVM instance to a
different physical machine at runtime. This feature has been available in WebLogic since the release of
version 9.0.
WebLogic Server can also support Service Migration which involves migration of specific pinned services
such as JMS and JTA. This blog entry however will focus entirely on Whole Server Migration including
the prerequisites for adopting it and the configuration steps required to set it up. In later posts, I will go
into some of the recommended functional testing steps that can be used to verify that Server Migration is
configured appropriately.
The information below has generally been written from a high-level point-of-view and assumes some
WebLogic knowledge. For a more detailed and less-assuming reference please refer to the official Oracle
documentation:
• Whole Server Migration
• Enterprise Deployment Guide: Server Migration
Prerequisites
In order to setup Server Migration the following is required:
• Floating IP Addresses
a unique address and port combination for each server instance
• Node Manager
a node manager for each physical machine and consistent netmask/interface configuration and OS platform
behavior across all machines
• Single Network Channel
no more than one network channel per server instance
• Shared Persistent Store
a highly available sharing mechanism to store server state
Configuration Steps
STEP 1: CREATE THE WEBLOGIC DOMAIN
Disclaimer: If you have basic WebLogic experience, this step should be fairly straight forward; if you don’t then you
may wish to track down some information on core WebLogic concepts and creating a domain.
In order to be able to test out Server Migration, your WebLogic domain will require the following
configuration as a minimum:
• Machine 1
• Admin Server*
• Managed Server 1
• Machine 2
• Managed Server 2
*Note: the Admin Server can only be manually migrated not automatically migrated.
Lastly, ensure the following conditions are met:
• Each WebLogic machine must be point to a unique running Node Manager instance (i.e. node
managers running on different physical or virtual machines)
• Each Managed Server must use a floating IP address for the host name. The floating IP address
for Managed Server 1 & 2 must be unique.
• The Admin Server must use a floating IP address for the host name if manual Admin Server
Migration support is required.
STEP 2: SETUP THE NODE MANAGER
The nodemanager.properties file for each Node Manager instance must be updated to indicate the
netmask and network device name (interface) to be used throughout the server migratable cluster.
Below is an example of the specific Node Manager properties that are required for server migration
configuration.
Sample Node Manager properties for “Server Migration”
Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true
The nodemanager.properties file is typically located relative to the FMW (or BEA) Home directory as
follows:
FMW_HOME/wlserver_10.3/server/lib
STEP 3: SETUP THE LEASING PROCESS
Leasing is the process WebLogic Server uses to enforce that a cluster node (or managed server) can
only be running on one physical machine at any given time. Leasing prevents the Node Manager from
erroneously starting a managed server that is already running on another machine.
There are two types of leasing configurations available:
• Consensus Leasing
leasing information is stored in-memory within a cluster member
• High-Availability Database Leasing
leasing information is stored in a high-availability database such as Oracle RAC
While, consensus leasing does not require any significant configuration steps (only the step to enable it in
WebLogic). Database leasing requires the following to be created within the database.
1. A tablespace for leasing information
create tablespace leasing logging datafile size 32m autoextend on next 32m
maxsize 2048m extent management local;
2. A schema/user assigned to the leasing tablespace
3. create user leasing identified by welcome1;
4. grant create table to leasing;
5. grant create session to leasing;
6. alter user leasing default tablespace leasing;
alter user leasing quota unlimited on leasing;
7. A table within the leasing schema
8. CREATE TABLE ACTIVE (
9. SERVER VARCHAR2(150) NOT NULL,
10. INSTANCE VARCHAR2(100) NOT NULL,
11. DOMAINNAME VARCHAR2(50) NOT NULL,
12. CLUSTERNAME VARCHAR2(50) NOT NULL,
13. TIMEOUT DATE,
14. PRIMARY KEY (SERVER, DOMAINNAME, CLUSTERNAME)
Once the leasing database has been setup, a JDBC Multi-Data Source or GridLink Data Source will need
to be configured in WebLogic to ensure access to the database at runtime.
STEP 4: GRANT SUPERUSER PRIVILEGES TO THE WLSIFCONFIG SCRIPT
Under the covers, WebLogic calls the wlsifconfig.sh script to facilitate the plumbing and unplumbing
of floating IP addresses. The following must be setup in order to support wlsifconfig execution from
WebLogic:
1. Ensure the PATH environment variable contains the following files:
• DOMAIN_HOME/bin/server_migration/wlsifconfig.sh
• WL_HOME/common/bin/wlscontrol.sh
• WL_HOME/common/nodemanager/nodemanager.domains
The changes to the PATH environment variable can be made to the setDomainEnv.sh file in the
DOMAIN_HOME/bin directory.
2. Make sure that OS commands required by the wlsifconfig.sh can be executed by the WebLogic
user. You can grant sudo execution privilege for the ifconfig and arping commands by adding the
following line to the /etc/sudoers file
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
In the example above, oracle is the name of the OS user for WebLogic.
STEP 5: ENABLE SERVER MIGRATION
The following steps can be followed to enable “Server Migration” via the WebLogic Admin Server.
1. Configure the WebLogic cluster(s):
1. From the Summary of Clusters screen, select the cluster requiring “Whole Server Migration”
configuration, then select the Migration tab
2. Under Candidate Machines For Migratable Servers select the machines you wish to be migration
candidates from the Available box and move them to the Chosen box
3. Set the Migration Basis as required ("Consensus" or "Database"). If using "Database" for
Migration Basis, set the Data Source For Automatic Migration to the previously created leasing Multi-
Data Source or GridLink Data Source.
2. Configure the WebLogic servers:
1. From the Summary of Servers screen, select the managed server requiring ”Whole Server
Migration” configuration, then select the Migration tab
2. Tick the Automatic Server Migration Enabled check box
3. Under Candidate Machines select the machines you wish to migrate to from the Available box and
move them to the Chosen box