Taking Notez – Island Pond Consulting

In today’s computing world many organizations will take advantage of public and private clouds for their production software deployments. One example of such software is IBM WebSphere Portal. In version 7 IBM introduced a new capability into IBM WebSphere Portal that leverages virtualized environments.

Before examining this feature it in important to keep in mind special considerations when running IBM WebSphere Portal in a virtual environment. The nature of the underlying virtualization platform will have a greater or lesser impact on the performance of WebSphere portal. In addition, despite having significant resources available in the host environment, care must be taken not to oversubscribe the resources of the underlying platform. That is to say, testing must be done to ensure that there is sufficient physical CPU and memory to service each virtual machine. According to IBM, a good rule for memory requirement is to double the WebSphere portal instances maximum heap size and use that as the virtual machine memory configuration. In addition keep in mind, “memory paging, both within the virtual machine and the hypervisor should be strictly avoided as that can lead to performance degradation.”

The technique for leveraging virtualized environments depends on the capabilities of the host platform and a process labeled localization of a new virtual machine instance. In the product documentation IBM cites VMware ESX as an example of an appropriate host platform.

The prerequisites for implementing a new virtual machine instance include the installation and configuration of a virtualization platform such as VMware ESX. In addition, on an existing virtual machine, you must install and at least partially configure IBM WebSphere portal. In the procedure that follows you will focus on the configuration of the IBM WebSphere application server as well as IBM WebSphere portal. A link to the documentation for localizing a new virtual machine instance on Windows can be found here (http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Localizing_a_new_virtual_machine_instance_on_Windows_wp7).

1. Stop the WebSphere Portal server. This can be done from the /bin directory of the portal profile. A typical path, on Windows, is C:\IBM\WebSphere\WP_profile\bin. The command executed is stopServer.bat WebSphere_Portal. Depending on the configuration of your system you may need to provide user credentials.
2. If not started, start server1. The command to start this server is done in the same directory as step 1. The command is, startServer.bat server1.
3. Before proceeding with changes to the WebSphere environment update the host name of the virtual computer according to the procedure for the operating system you are using.
4. Using the wsadmin scripting tool execute a changeHostName task. wsadmin -c “$AdminTask changeHostName -hostName newHostName”. In this example the wsadmin script is executed in console mode. Wsadmin interacts with Java management extension objects and, in this case, with the AdminTask object.
5. An optional step is to rename the node structure of the WebSphere application server configuration. The purpose of this change is to ensure a unique node name in the event that the new node will be federated into a network deployment cell. The syntax for this command is wsadmin -c “$AdminTask renameNode -nodeName oldNodeName -newNodeName newNodeName”
6. In addition to changes made to this point script files must also be updated to reflect the changed node name. Edit the setupCmdLIne.bat file in wp_profile\bin directory and update the property, WAS_NODE= to reflect the new name of the node referenced in step 5 above.
7. One of the scripting environments for managing IBM WebSphere Portal is ConfigEngine.bat. This scripting tool is used to complete the node rename process as understood by IBM WebSphere Portal. The path to this tool is, typically, C:\IBM\WebSphere\wp_profile\ConfigEngine. From this context execute ConfigEngine.bat rename-node-in-cell-registry -DWasPassword=WASAdminPassword –DpreviousNodeName=oldNodeName. The password to be provided here is the one used by the WebSphere application server administrator. Parameters that begin with “D” are an indicator that the command line argument takes precedence over values stored in files such as wkplc.properties found in wp_profile\ConfigEngine\properties.
8. Now that the environment is ready for the localization of the WebSphere Portal instance you must execute the localize-clone task. This update derives information from the WebSphere Application Server configuration. Execute ConfigeEngine.bat localize-clone -DWasPassword=password
9. The final task for localizing a new virtual machine instance is to clear any existing schedule tasks. This is because existing tasks could reference the old hostname. Execute ConfigEngine.bat action-clean-scheduled-tasks -DWasPassword=password
10. Optionally it is possible that your WebSphere Portal instance was set up to use an existing Windows service. If so the service still references the old host name and node name in order to resolve this you will need to execute the WASservice command to create a new Windows service entry and, for that matter, to remove the old window service entry.
11. The final step to complete localization of a virtual machine instance is to restart server1 and then stop server1. Following this, start WebSphere_Portal.

A couple tips to keep in mind:
Consider using a snapshot of your new clone as a point in time recovery in your attempts to localize a new virtual machine instance. This will permit you to easily discard a failed attempt and start over.

Keep in mind your ultimate WebSphere Portal deployment scenario. For example, if you intend to deploy a WebSphere Portal farm you might wish to more completely configure your IBM WebSphere Portal before cloning the virtual machine. In contrast, if you are building an IBM WebSphere network deployment cluster you will wish to defer configuration of the first instance with regard to global security and database integration.

Perhaps the best use case for localization of virtual machines is for testing and development support. In any case the advantages of virtualization are significant and offer organizations greater flexibility and opportunities for increasingly rapid deployments.