Weblogic Server Migration

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
================

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.

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.
Figure 1-1 Example 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.
Table 1-1 Upgrade Requirements for Components in Example WebLogic Application Environment
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.

How the Upgrade Wizard Simplifies the Upgrade Process
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.
Interoperability and Compatibility with Previous Releases
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




1 comment: