WAS Migration

Migration
This term has many definitions and a broad scope. In this document, the meaning of migration is limited to the actions associated with moving Java™ 2 Enterprise Edition (J2EE™) applications (EARs) and Application Server configuration data (such as resources and security settings) from a previous version of Application Server to V6.

WASPreUpgrade (tool)
Refers to the first step of the two-step migration process. The tool associated with this step will extract information from the previous version of Application Server and store it in a backup directory. This tool can be run by itself from the command line or as part of the migration wizard.

WASPostUpgrade (tool)
Refers to the second step of the two-step migration process. The tool associated with this step will take information from a directory created by the WASPreUpgrade tool and import it into a V6 profile. This tool can be run by itself from the command line or as part of the migration wizard.

Backup directory
Refers to a directory structure created by the WASPreUpgrade tool that contains all the information necessary for migration from the previous version of Application Server.

Migration wizard
Refers to the graphical user interface (GUI) that interactively performs the migration. This GUI tool performs the WASPreUpgrade and WASPostUpgrade steps.

FirstSteps (tool)
Tool provided in V6 to simplify and organize many actions that customers may wish to perform with a newly installed system. It can be found in the firststeps directory under each profile and can be used to launch the migration wizard.

Profiles
This concept expands on the idea of "instances" in V5. It refers to the collection of all the configuration data for an Application Server in V6. Application Server V6 provides for multiple profiles with only one install of the binaries. A single profile is required as the destination for the data being migrated from a previous version. (See Installing Application Server V6.)

Cell
Refers to the collection of one or more nodes controlled by a single deployment manager.

Federate or Federated
Refers to the action of adding a node to a cell; also refers to a node that is part of a cell. This term has been expanded to also refer to a node in a multi-node V4 domain.

Deployment manager profile (dmgr profile)
This profile acts as the deployment manager, and is the destination for the migration of the V5 deployment manager, and as a new deployment manager for V4 migrations. There can be only one deployment manager profile for each cell.

Standalone or Application Server profile
Refers to a profile that is analogous to a single node install of Application Server. This type of profile is the destination for the migrations of a node either in a cell or not in a cell.

Clusters
This term replaces the idea of ServerGroups from V4. Clusters are sets of servers that are used for distributing workload within a cell.


A quick guide for migrating to IBM WebSphere Application Server V6
Posted by WebSphere at 2/16/2009 07:40:00 PM 1 comments
Labels: faq, WebSphere
2/9/09
security.xml file is corrupted

If security.xml file is corrupted how will restore it?
First, what is file corruption?
Corrupted files are files that suddenly become inoperable or unusable. There are several reasons why a file may become corrupted. In some cases, it is possible to recover and fix the corrupted file, while at other times it may be necessary to delete the file and replace it with an earlier saved version.

What are the chances of security.xml becoming corrupted? There are chances for any config file to become corrupted.

Things to understand:-
1. How to avoid this?
2. What to do when this happens?

1. How to avoid this?
When you plan to edit Security.xml or any configuration file, better to take a hard copy back up or run backupConfig script. Hard copy backup, cp file as security_bak.xml, then make make changes to security.

2. What to do when this happens?
Say, on 5th, Tuesday, Feb you made changes to your security, it got fat fingured or corrupted, goto your system admin, revert it back to last working copy.
I would do like this. I would talk to my system admin and ask him to load security.xml from lastnights backup. We at our office, have nightly backups and weekly backups. We retain a months historical backups.

OR - If you know your security model completely, you can manually goto security.xml file, set security to false. save and recycle your server. It sets secutiy to false means no security. Now, set your security again.

Again, When will you modify security.xml? This is not an every day task. You will edit your security at the time of setting up new installation, or when you have a change in LDAP info or, when there is a need to add a new user or group etc. So, its always a good practice to take security.xml backup before you modify it.

There is even a better way to do this, specially in Production Environments. Let your versioning system take care of it. Meaning, check in your configuration into a version control system. If you make any change, it can be tracked.