Wednesday 19 March 2014

Migrating WebSphere Application Server 7.0 to Version 8.0



IBM provides several tools to make migration from an earlier version as smooth as possible. WAS v8.0 migration tools support the migration from WAS v6.0, v6.1 and v7.0


There are many things to be migrated, but the most important things are:
Migration of application server configuration (profile)
Migration of applications


1.Execute WASPreUpgrade.sh tool and create backup directory
2.Create a new target profile using PMT/manageprofiles.sh
3.Execute WASPostUpgrade.sh tool and complete migration

The WASPreUpgrade.sh script copies the configuration of WAS 7.0 version of dmgr profile to a directory. This backup can then be utilized by WASPostUpgrade.sh script to complete the migration. Note that this backup is not the same as the one created by backupConfig command. This backup mainly acts as the staging directory for migration and is tailor-made for migration. Remember to execute these scripts from /bin directory of WAS 8.0.

WASPostUpgrade.sh command

We completed the creation of a new WAS 8.0 dmgr profile. Now run WASPostUpgrade.sh command. This command supports “-replacePorts true” option which maps the ports from the source to the target profile. When there is a port conflict, WASPostUpgrade.sh tool automatically uses the next higher port value. It is also possible to provide a base port number with the help of “-portBlock” parameter for the allocation of new ports. If you do that, any new port numbers assigned will start from the base port number.

The “–includeApps true” parameter forces the tool to install user applications also.

WebSphere ND 8.0 Migration

1. Migration of a Deployment Manager

DMGR Migration Prerequisites:

1. Ensure that the latest recommended updates for WAS and SDK code are installed on the primary and all secondary dmgr machines.

2. Verify that the maximum heap size for the dmgr and nodeagents to be migrated has been set to 1024 mb (1 GB).

3. Ensure that a WAS 8.0 dmgr profile exists; if not, go to ‘Create a “dmgr” profile’ (Uncheck the box for ‘Enable administrative security’; use Default port values when creating the profile.)

Verify all values match the previous dmgr configuration (Node name, Host name, Cell name). Be sure to check if a DNS alias was used for the dmgr host name.

4. If Introscope monitoring is in use, the generic jvm arguments will have to change at migration time, before starting the upgraded dmgr. Remove the old Introscope entries from the dmgr jvm arguments (and the old ODC parameter), save and sync.

5. Verify that the newer JVM Custom Property ODCGroup.disabled is set to true on each java process (dmgr, nodeagent, app servers)

6. Verify the following Generic JVM Arguments are included on each java process (dmgr, nodeagent, app servers)

7. To resolve a potential timeout issue during migration, verify the update of the WAS 7.0 com.ibm.SOAP.requestTimeout=8000 (from the default of 180) on the dmgr profile and on every node profile in the cell.

8. Verify that automatic heapdump and javacore on dmgr and all nodeagents are turned off.

9. On the Admin Console, disable ‘AutoSync’ on all nodeagents, and bounce the nodeagents. For each nodeagent.

10. Verify that there is sufficient free space in the /appl/wasbackup filesystem for config backups and migration logs.

11. Stop and restart the dmgr to pick up the above changes

12. Stop and restart the nodeagents to pick up the above changes

13. Comment out websphe cron entries to avoid collisions during migration; cancel scheduled reboot if necessary.

Begin DMGR Migration

Run a backup configuration of the current WAS 7.x NodeAgent(s) on each nodeagent box

Run a backup configuration of the current WAS 7.0 Deployment Manager

Run WAS PreUpgrade script

This command run from <was80_Home>/bin
In my environment was8_home is /u02/local/opt/was/was80 

[kumar@bharath bin]$ ./WASPreUpgrade.sh /u02/local/opt/was/backup /u03/local/opt/was/was70 -oldProfile dmgr

IBM WebSphere Application Server, Release 8.0
Product Upgrade PreUpgrade tool, Version 1.0
Copyright IBM Corp., 1997-2010

MIGR0300I: The migration function is starting to save the existing Application Server environment.
MIGR0302I: The existing files are being saved.
MIGR0385I: Starting to save profile dmgr.
MIGR0425I: A deployment manager migration is detected. Before continuing with the WASPostUpgrade process, run the backupConfig command on your federated nodes.
MIGR0303I: The existing Application Server environment is saved.
MIGR0420I: The first step of migration completed successfully.

Check the PreUpgrade logs for warnings or errors:

more /u02/local/opt/was/backup /logs/WASPreUpgrade*log
more /u02/local/opt/was/backup /logs/WASPreUpgrade.trace

Bring up the old WAS 7.0 Deployment Manager

/u03/local/opt/was/was70/profiles/dmgr/bin/startManager.sh

Verify that the nodeagents can sync successfully with dmgr, either through console sync request, or manual sync. If not, resolve this sync problem, and start the migration process over from the beginning.

Run WAS PostUpgrade script

[kumar@bharath bin]$ ./WASPostUpgrade.sh /u02/local/opt/was/backup -oldProfile dmgr -profileName dmgr -replacePorts true -includeApps true -scriptCompatibility true -username wasadmin -password password

IBM WebSphere Application Server, Release 8.0
Product Upgrade PostUpgrade tool, Version 1.0
Copyright IBM Corp., 1997-2010
MIGR0304I: The previous WebSphere environment is being merged into this profile.
MIGR0367I: Backing up the current Application Server environment.
CEIMI0006I Starting the migration of Common Event Infrastructure.
CWPST9006W: The application server did not migrate the defaultBindings.xml default bindings file because the file exists in the new system.
CWPST9004W: The application server did not migrate the Provider sample binding because a binding with the same name exists in the new system.
CWPST9004W: The application server did not migrate the Client sample binding because a binding with the same name exists in the new system.
MIGR0229I: The migration function is updating the attributes of SSLConfig entry CellDefaultSSLSettings. This entry is already defined in the existing model.
MIGR0223I: The migration function is adding SSLConfig entry NodeDefaultSSLSettings to the model.
MIGR0486I: The Transports setting in file server.xml is deprecated.
MIGR0486I: The PMIService:initialSpecLevel setting in file server.xml is deprecated.
MIGR0339I: Application ibmARS.ear is deploying using the wsadmin command.
MIGR0499I: Application ibmARS.ear successfully deployed using the wsadmin command.
MIGR0339I: Application usg_war.ear is deploying using the wsadmin command.
MIGR0499I: Application usg_war.ear successfully deployed using the wsadmin command.
MIGR0339I: Application commsvc.ear is deploying using the wsadmin command.
MIGR0499I: Application commsvc.ear successfully deployed using the wsadmin command.
MIGR0379W: Do not use the existing deployment manager in the old configuration. It has been disabled.
CEIMI0007I The Common Event Infrastructure migration is complete.
MIGR0307I: The restoration of the previous Application Server environment is complete.
MIGR0271W: Migration completed successfully, with one or more warnings.

[kumar@bharath bin]$

WASPostUpgrade logs can be found in:

/u02/local/opt/was/backup /logs/WASPostUpgrade.dmgr*log
/u02/local/opt/was/backup /logs/WASPostUpgrade.dmgr.trace

Note that this script may run for several hours, depending on the number and size of the deployed applications in the cell. You can check to log to see how many applications have completed.

Investigate and resolve any errors or warnings before proceeding.

Back up the new WAS 8.0 configuration

Shutdown WAS 7.0 DMGR and bring up WAS 8.0 DMGR
On the primary machine
cd /u03/local/opt/was/was70/profiles/dmgr/bin

mv startManager.sh startManager.sh.disabled

Update WAS Global Security settings
finally bounce the dmgr.

Migration of a Node

1. Ensure WAS 8.0 code is installed, and all recommended refresh packs/fixpacks/ifixes have been applied on the node; and that the dmgr update/patch level is equal to or higher than the node. Also verify sufficient disk space in the dmgr, node, and backup filesystems.

2. Ensure that a node profile exists; if not, go to ‘Create a “node” profile. Verify all values match the previous node configuration (Host name of dmgr, Node name, Host name of node machine). Be sure to check if a DNS alias was used for the dmgr host name

3. Ensure WAS 8.0 DMGR is running (with sufficient ulimit for open files); update cron on the dmgr machine if necessary to prevent collisions (backup, ftp, etc.)

4. Check for adequate disk space on the dmgr and the node machine, in the /appl/wasbackup and /u02/local/opt/was/was80/profiles filesystems, to hold additional backup copies of the configuration.\

5. Verify that the maximum heap size for the nodeagent to be migrated has been set to 1024 mb (1 GB).

6. Verify that the following Generic JVM Arguments are included on each java process (dmgr, nodeagent, app servers, BISTemplate, etc.):

-Djava.net.preferIPv4Stack=true -Dcom.ibm.cacheLocalHost=true

Also, for nodeagents, verify that the Generic JVM Arguments includes this parameter:
-Djava.awt.headless=true

Begin Node Migration

Before migrating the first node, verify that all running nodeagents have synchronized with the dmgr before continuing.

After the first node has been migrated, before migrating subsequent nodes in the cell, verify that all previously migrated nodes have synchronized with the dmgr before continuing.

1. Run a backup configuration of the current WAS 8.0 Deployment Manager

2. Bring down WAS 7.0 AppServers on the box being migrated using the Admin Console; then stop the nodeagent, and stop all other logagent and rmiregistry processes (except the deployment manager) on the node, as follows:
On the admin console, do a normal stop of all appservers on the node (can do several at a time; save the BootstrapServer and BridgeServer for last); then stop the nodeagent via command line.

Ensure that the node profile exists on the node to be migrated; if not, go to Create Profile for “node”
Verify that the WAS 8.0 dmgr is up and running.

Run WAS PreUpgrade script

[kumar@bharath bin]$ ./WASPreUpgrade.sh /u02/local/opt/was/backup1 /u03/local/opt/was/was70 - oldProfile node01

IBM WebSphere Application Server, Release 8.0
Product Upgrade PreUpgrade tool, Version 1.0
Copyright IBM Corp., 1997-2010
MIGR0300I: The migration function is starting to save the existing Application Server environment.
MIGR0302I: The existing files are being saved.
MIGR0385I: Starting to save profile node01.
MIGR0303I: The existing Application Server environment is saved.
MIGR0420I: The first step of migration completed successfully.

WASPreUpgrade log messages can be found in:
/u02/local/opt/was/backup1 /logs/WASPreUpgrade.<date>.log

Run WAS PostUpgrade script:

[kumar@bharath bin]$ ./WASPostUpgrade.sh /u02/local/opt/was/backup/node -oldProfile node -profileName node -replacePorts true -includeApps true

IBM WebSphere Application Server, Release 8.0
Product Upgrade PostUpgrade tool, Version 1.0
Copyright IBM Corp., 19972010
MIGR0304I: The previous WebSphere environment is being merged into this profile.
MIGR0367I: Backing up the current Application Server environment.
CEIMI0006I Starting the migration of Common Event Infrastructure.
MIGR0486I: The Transports setting in file server.xml is deprecated.
MIGR0486I: The PMIService:initialSpecLevel setting in file server.xml is deprecated.
MIGR0486I: The PMIService:initialSpecLevel setting in file server.xml is deprecated.
MIGR0404W: Do not use the node agent in the old configuration. It has been disabled.
MIGR0339I: Application ibmARS.ear is deploying using the wsadmin command.
MIGR0499I: Application ibmARS.ear successfully deployed using the wsadmin command.
MIGR0351I: The migration function is attempting to synchronize with the deployment manager using the SOAP protocol.
MIGR0241I: Output of syncNode.
ADMU0116I: Tool information is being logged in file
/u02/local/opt/was/was80/profiles/node/logs/syncNode.log
ADMU0128I: Starting tool with the node profile
ADMU0401I: Begin syncNode operation for node Node01 with Deployment Manager bharath.tech.com: 8879
ADMU0016I: Synchronizing configuration between node and cell.
ADMU0402I: The configuration for node Node01 has been synchronized with
Deployment Manager bharath.tech.com: 8879
MIGR0352I: The synchronization with the deployment manager is successful.
CEIMI0007I The Common Event Infrastructure migration is complete.
MIGR0307I: The restoration of the previous Application Server environment is complete.
MIGR0271W: Migration completed successfully, with one or more warnings.

WASPostUpgrade log messages can be found in
/u02/local/opt/was/backup/node/logs/WASPostUpgrade*.log

The dmgr also records some migration messages in the dmgr SystemOut.log.

Turn on Autosync for the migrated node:
Disable WAS 7.0 node and server startup:
cd /u03/local/opt/was/was70/profiles/node/bin
mv startNode.sh startNode.sh.disabled
mv startServer.sh startServer.sh.disabled

Post Migration Follow-up

1. Verify that automated backups of dmgr (in cron) are successful.
2. Clean up space on the dmgr machine in …./dmgr/temp/ and in backup directories; move backups to archive location if desired.
3. Check for port conflicts following restart using this command, resolve as needed:
4 Uninstall old WAS 7 code, after all processes

Rollback of entire cell to WAS 7.0

In this case, the dmgr is rolled back to WAS 7.0, as well as any nodes and IHS that had been migrated.

1. Stop all app servers, nodeagents, logagents, IHS processes, etc., and dmgr in the cell

2. Disable the WAS 8.0 dmgr start script:

mv /u02/local/opt/was/was80/profiles/dmgr/bin/startManager.sh /u02/local/opt/was/was80/profiles/dmgr/bin/startManager.sh.disabled

3. Restore the dmgr WAS 7.0 configuration from the backup taken just before the dmgr was migrated
/u03/local/opt/was/was70/profiles/dmgr/bin/restoreConfig.sh <Backup_filename>

4. Start the WAS 7.0 dmgr

mv /u03/local/opt/was/was70/profiles/dmgr/bin/startManager.sh.disabled /u03/local/opt/was/was70/profiles/dmgr/bin/startManager.sh

/u03/local/opt/was/was70/profiles/dmgr/bin/startManager.sh

5. If Introscope monitoring is in use, the generic jvm arguments were changed at migration time. Add the old Introscope entries back to the dmgr jvm arguments, save and sync.

6. Start each WAS 7.0 nodeagent.

7. On the Admin Console, enable ‘AutoSync’ on all nodeagents. For each nodeagent.

No comments: