ShowTable of Contents
Before You Begin
Purpose of document
The process of cloning a WebSphere Portal environment means to make an exact copy of your current configuration, and deploy it to another system. This can save you time from having to reconfigure databases, security or redeploy any custom applications.
Cloning documents have been provided for previous versions of WebSphere Portal:
WebSphere Portal v6.1
WebSphere Portal v7.0
However these documents are limited to cloning standalone environments.
This guide provides a method to clone a
cluster for WebSphere Portal v8. If you are using VMWare images however, you may find this guide for Portal v8 clusters more useful:
WebSphere Portal v8 on VM images
Source Portal Environment
This guide assumes that you already have a functional WebSphere Portal v8 Cluster, and it is completely configured for your use. This includes, but is not limited to:
- Database-transfer completed
- Enabled for your LDAP
- Custom applications and themes deployed
- Custom context roots in use
Deployment Scenarios
Cloning a WebSphere Portal environment can be useful in the following scenarios:
- Creating a backup/disaster recovery site
- Moving Portal from one server/datacenter to another
- Creating custom installation images for multiple deployments
- Creating different types of environments (Staging, Pre-Production, etc)
Limitations
By using this method, there are certain limitations that must be adhered to:
- Operating System and Bit versions must be identical between source and target servers. If your source Portal cluster is deployed to 64-bit Red Hat Linux 6, then your target Portal must also be deployed to 64-bit Red Hat Linux 6.
- File paths must be identical between source and target servers. If your source Portal cluster uses an installation path of /opt/IBM/WebSphere/PortalServer, then your target Portal cluster must also use an installation path of /opt/IBM/WebSphere/PortalServer
- Source environment must be brought down to create the clone.
- You cannot change the Cell name or Cluster name when deploying the clone. These have to be the same values for each new environment.
Environment Used for this Guide
For this guide, I used a standard 2 horizontal node cluster connected to DB2 and IBM Directory Server, with IBM HTTP Server. The versions used are:
- WebSphere Portal Extend v8.0.0.1
- WebSphere Application Server v8.0.0.5
- IBM HTTP Server v8.0.0.0
- DB2 9.7 FP4
- IDS v6.3
Each Portal Node contained one nodeagent and one WebSphere_Portal JVM. My DB2 database consisted of 6 databases: RELDB, COMDB, CUSDB, JCRDB, LMDB, and FDBKDB.
Since multiple Portal environments can share the same LDAP server, this guide does NOT cover copying the LDAP to another server. Your clone will continue to use the exact same LDAP as the source Portal.
Create WAS/Portal custom repository
This section is completely optional. In this section, we will combine the WAS, Portal and IHS repositories into a single repository. You can then store the single repository on a centrally located server so that other servers can map/mount to it. If you use live repositories, you may not find this particularly useful, but it should still work nevertheless.
The instructions for this process can be found on the following page:
Using IBM Packaging Utility to combine Portal packages
Backup Source Portal Cluster Profiles
In this section, we will use the manageprofiles command to back up the Primary Portal Node, Additional Node profiles, and the Deployment Manager. These commands will generate zip files that contain the entire profile configuration. The sizes of these zip files will vary, depending on your usage of WebSphere Portal.
Backup the Primary Node
Note: To reduce the size of the Primary Node profile backup, you can clear the contents of, or archive, the following directories:
<wp_profile>/wstemp
<wp_profile>/temp
<wp_profile>/PortalServer/deployed
The PortalServer/deployed directory contains a copy of every war file that has ever been deployed against the WebSphere Portal environment, and can cause this directory to be very large. These are not used by Portal during runtime, so removing them has no impact on Portal functionality. However, xmlaccess exports by default will reference the war files in <url> tags of any web-app objects. If you intend to export and import web-apps from one environment to another and you have cleared or archived the contents of PortalServer/deployed, then extra care will need to be taken to ensure the <url> tags are correct in the xmlaccess import file.
- Stop the WebSphere_Portal server on the Primary Node by executing the following command from the <wp_profile>/bin directory:
Windows: stopServer.bat WebSphere_Portal -user <dmgr admin user> -password <dmgr admin password>
Linux/UNIX: ./stopServer.sh WebSphere_Portal -user <dmgr admin user> -password <dmgr admin password>
Note: If you have vertical cluster members on the Primary Node, stop those servers as well.
- Stop the NodeAgent on the Primary Node by executing the following command from the <wp_profile>/bin directory:
Windows: stopNode.bat -user <dmgr admin user> -password <dmgr admin password>
Linux/UNIX: ./stopNode.sh -user <dmgr admin user> -password <dmgr admin password>
- If you have a webserver defined on this node, stop it as well:
Windows: stopServer.bat webserver1 -user <dmgr admin user> -password <dmgr admin password>
Linux/UNIX: ./stopServer.sh webserver1 -user <dmgr admin user> -password <dmgr admin password>
- Clear any references to the Portal hostname in the database by executing this ConfigEngine command from the <wp_profile>/ConfigEngine directory:
Windows: ConfigEngine.bat action-clean-scheduled-tasks -DWasPassword=<dmgr admin password> -DPortalAdminPwd=<portal admin password>
Linux/UNIX: ./ConfigEngine.sh action-clean-scheduled-tasks -DWasPassword=<dmgr admin password> -DPortalAdminPwd=<portal admin password>
- Backup the Primary Node profile by executing the following command from the <wp_profile's AppServer root>/bin directory:
Windows: manageprofiles.bat -backupProfile -profileName <wp profile name> -backupFile <full path to a zip file>
Linux/UNIX: ./manageprofiles.sh -backupProfile -profileName <wp profile name> -backupFile <full path to a zip file>
Note: The zip file you pass in for the -backupFile parameter will be created by the command. It can be anything you'd like, but name it so that you'll know what it is. For example:
./manageprofiles.sh -backupProfile -profileName wp_profile -backupFile /opt/WPBackups/wpProfile1Backup.zip
For my environment, this process took roughly 5 minutes and generated a 491.3 MB zip file.
Backup Additional Nodes
Note: To reduce the size of the Additional Node profile backup, you can clear the contents of, or archive, the following directories:
<wp_profile>/wstemp
<wp_profile>/temp
<wp_profile>/PortalServer/deployed
In typical Cluster scenarios, application deployments will be made against the Primary Portal server and not Additional Portal servers, so the PortalServer/deployed directory may be very small compared to the Primary Node.
- Stop the WebSphere_Portal server on the Additional Node by executing the following command from the <wp_profile>/bin directory:
Windows: stopServer.bat WebSphere_Portal_2 -user <dmgr admin user> -password <dmgr admin password>
Linux/UNIX: ./stopServer.sh WebSphere_Portal_2 -user <dmgr admin user> -password <dmgr admin password>
Note: In the command examples, WebSphere_Portal_2 is used as the additional cluster Portal member name. Use whatever is valid for your environment.
Note: If you have vertical cluster members on the additional node, stop those as well.
- Stop the NodeAgent on the Additional Node by executing the following command from the <wp_profile>/bin directory:
Windows: stopNode.bat -user <dmgr admin user> -password <dmgr admin password>
Linux/UNIX: ./stopNode.sh -user <dmgr admin user> -password <dmgr admin password>
- If you have a webserver defined on this node, stop it as well:
Windows: stopServer.bat webserver1 -user <dmgr admin user> -password <dmgr admin password>
Linux/UNIX: ./stopServer.sh webserver1 -user <dmgr admin user> -password <dmgr admin password>
- Backup the Additional Node profile by executing the following command from the <wp_profile's AppServer root>/bin directory:
Windows: manageprofiles.bat -backupProfile -profileName <wp profile name> -backupFile <full path to a zip file>
Linux/UNIX: ./manageprofiles.sh -backupProfile -profileName <wp profile name> -backupFile <full path to a zip file>
Note: The zip file you pass in for the -backupFile parameter will be created by the command. It can be anything you'd like, but name it so that you'll know what it is. For example:
./manageprofiles.sh -backupProfile -profileName wp_profile -backupFile /opt/WPBackups/wpProfile2Backup.zip
- Repeat this process for each additional node you have.
Backup the Deployment Manager
Note: To reduce the size of the Deployment Manager profile backup, you can clear the contents of, or archive, the following directories:
<dmgr_profile>/wstemp
<dmgr_profile>/temp
- Stop the Deployment Manager by executing the following command from the <dmgr_profile>/bin directory:
Windows: stopManager.bat -user <dmgr admin user> -password <dmgr admin password>
Linux/UNIX: ./stopManager.sh -user <dmgr admin user> -password <dmgr admin password>
- If you have a webserver defined on this node, stop it as well:
Windows: stopServer.bat webserver1 -user <dmgr admin user> -password <dmgr admin password>
Linux/UNIX: ./stopServer.sh webserver1 -user <dmgr admin user> -password <dmgr admin password>
- Backup the DMGR profile by executing the following command from the <dmgr's AppServer root>/bin directory:
Windows: manageprofiles.bat -backupProfile -profileName <dmgr profile name> -backupFile <full path to a zip file>
Linux/UNIX: ./manageprofiles.sh -backupProfile -profileName <dmgr profile name> -backupFile <full path to a zip file>
Note: The zip file you pass in for the -backupFile parameter will be created by the command. It can be anything you'd like, but name it so that you'll know what it is. For example:
./manageprofiles.sh -backupProfile -profileName Dmgr01 -backupFile /opt/WPBackups/dmgrProfileBackup.zip
For me, this process took 2 minutes and generated a 119.3 MB zip file.
Additional Files To Backup
If your Portal environment depends on any files that are stored outside of the profiles, collect these separately now. This includes any of the following:
- Java Libraries and custom jars (including any in AppServer/lib)
- Database drivers
- Any files that custom applications depend on outside of anything in the profile path
Backup Source Portal Databases
For the purposes of this guide, DB2 V9.7 was used as the backend database and contains 6 Portal databases:
RELDB
CUSDB
COMDB
JCRDB
LMDB
FDBKDB
The DB2 command 'BACKUP DATABASE' will be used to backup each database. If you are using Oracle or SQLServer, consult with your DBA on a proper method to backup the Portal databases.
For DB2, the process I followed was:
- Log in to the Database Server as the Database Administrator
- Execute the following command for each database:
db2 BACKUP DATABASE <db_name> TO <temporary directory>
For example:
db2 BACKUP DATABASE reldb TO /home/db2inst1/DBbackups/reldb
The size of the database backups will vary depending on your usage of Portal and WCM. For my system under minimal usage, I had the following sizings:
/home/db2inst1/DBbackups/reldb ==> 288.1 MB
/home/db2inst1/DBbackups/cusdb ==> 175.6 MB
/home/db2inst1/DBbackups/comdb ==> 208.1 MB
/home/db2inst1/DBbackups/jcrdb ==> 360.4 MB
/home/db2inst1/DBbackups/lmdb ==> 127.6 MB
/home/db2inst1/DBbackups/fdbkdb ==> 161.1 MB
And when the DBbackups directory is archived (DBbackups.tar.gz), 80.1 MB total. Archiving the process is optional but will help significantly if you plan on moving the databases to a new server.
Checkpoint 1
At this point, you have successfully created a clone/backup of your Portal Cluster. This clone/backup includes:
- Combined IBM Installation Manager Repository (optional)
- Primary Portal profile backup (wpProfile1Backup.zip in my example)
- Additional Portal profile backup (wpProfile2Backup.zip in my example)
- DMGR profile backup (dmgrProfileBackup.zip in my example)
- Portal Database backup (DBbackups.tar.gz in my example)
These items combined make our cloned image, so do not lose track of them.
If you plan to continue using your source WebSphere Portal environment, you can do so now. We will not be using it again for this process.
Install the Clone
In this section, we will deploy the clone using the files created from the source environment. This includes installing our new Deployment Manager and Portal nodes, restoring the databases and connecting Portal to them, and updating the Portal Cluster configuration for the new hostname of the environment.
Install the Primary Portal Node
These steps assume you are using a custom installation repository created earlier in this guide. If you chose not to do this and are instead installing WebSphere Portal using a Live Repository or Passport Advantage, please keep the following
important details in mind in order to have a successful clone installation:
- You must use the exact same installation path that you used for the Source Portal. If your Source Portal was installed to /opt/IBM/WebSphere/AppServer and /opt/IBM/WebSphere/PortalServer, then your Target Portal must be installed to those same same directory paths on the new server.
- Install a BINARY Portal. You do this by de-selecting the Portal profile option in the Portal features section of the installation.
- Copy the custom repository to the target server, or map/mount a drive to the custom repository so that the target server can access it.
- Install IBM Installation Manager by launching the installer from the <custom repository>/IIM/<os_type> directory:
Windows: installc.exe -acceptLicense
Linux/UNIX: ./installc -acceptLicense
Note: This command silently installs IBM Installation Manager as an administrative user. If you would prefer to install it using a graphical installer, then use the "install.exe" or "install" files instead. It is entirely up to you.
- Launch IBM Installation Manager from the <InstallationManager root>/eclipse directory:
Windows: IBMIM.exe
Linux/UNIX: ./IBMIM
- Go to Files -> Repositories and click Add
- Enter the path for your <custom repository>/repository/repository.config file, for example:
/opt/media/WP8001Clone/repository/repository.config
- Click OK to save changes.
- On the Installation Manager launch screen, click Install. Check the boxes to install WebSphere Application Server and WebSphere Portal Server and your Offering (for example, Extend):
NOTE: This screen may vary depending on the Offering you are installing. In this example, we are installing Portal Extend, so we select both Server and Extend. If you were installing WCM, you would select both Server and WCM. If you were installing just Server, you would only select Server.
- Click Next.
- Accept the license agreement and click Next.
- Select your desired location of the Shared Resources directory and click Next.
- Click IBM WebSphere Application Server to set the installation directory for WebSphere Application Server.
NOTE: This path must be identical to the path from your source Portal Installation. If your source Portal used /opt/IBM/WebSphere/AppServer, then this installation must also use /opt/IBM/WebSphere/AppServer.
- Click IBM WebSphere Portal Server to set the installation directory for WebSphere Portal Server.
NOTE: This path must be identical to the path from your source Portal Installation. If your source Portal used /opt/IBM/WebSphere/PortalServer, then this installation must also use /opt/IBM/WebSphere/PortalServer.
- Click Next.
- On the Features screen, de-select the "Portal Server Profile" option. We need to install a Binary Portal installation only.
- Click Next.
- Click Install to install the products.
NOTE: Review the summary screen. If "Portal Server Profile" is listed in the features, go back to the Features screen and remove it.
- After installation completes, select the radio button for NONE and exit IBM Installation Manager.
- If you had a Portal Cumulative Fix installed on the source Portal server, go ahead and install that now to your new server. It must be done after the initial Portal base installation completes.
Install the Additional Portal Node
Repeat the primary node process for each additional node you intend to have. Remember to keep these points in mind:
- You must use the exact same installation path that you used for the Source Portal. If your Source Portal was installed to /opt/IBM/WebSphere/AppServer and /opt/IBM/WebSphere/PortalServer, then your Target Portal must be installed to those same directory paths on the new server.
- Install a BINARY Portal. You do this by de-selecting the Portal profile option in the Portal features section of the installation.
Install the Deployment Manager
This section is only needed if you intend to install the Deployment Manager on a separate server from the Portal server. If your Deployment Manager will be local to the Portal Primary node, then you have nothing further to install.
Like the previous sections to install the Portal nodes, this section assumes you are using the custom repository created earlier. If you would prefer to install the WAS environment using a Live Repository or Passport Advantage, that is perfectly fine.
- Copy the custom repository to the target server, or map/mount a drive to the custom repository so that the target server can access it.
- Install IBM Installation Manager by launching the installer from the <custom repository>/IIM/<os_type> directory:
Windows: installc.exe -acceptLicense
Linux/UNIX: ./installc -acceptLicense
Note: This command silently installs IBM Installation Manager as an administrative user. If you would prefer to install it using a graphical installer, then use the "install.exe" or "install" files instead. It is entirely up to you.
- Launch IBM Installation Manager from the <InstallationManager root>/eclipse directory:
Windows: IBMIM.exe
Linux/UNIX: ./IBMIM
- Go to Files -> Repositories and click Add
- Enter the path for your <custom repository>/repository/repository.config file, for example:
/opt/media/WP8001Clone/repository/repository.config
- Click OK to save changes.
- On the Installation Manager launch screen, click Install. Check the box to install WebSphere Application Server only.
- Click Next.
- Accept the license agreement and click Next.
- Select your desired location of the Shared Resources directory and click Next.
- Click IBM WebSphere Application Server to set the installation directory for WebSphere Application Server.
NOTE: This path must be identical to the path from your source Deployment Manager Installation. If your source Deployment Manager used /opt/IBM/WebSphere/AppServer, then this installation must also use /opt/IBM/WebSphere/AppServer.
- Proceed through the rest of the screens. For my installation, I left all of the defaults selected.
- When the installation completes, select the radio button for NONE and exit IBM Installation Manager.
Checkpoint 2
At this point, you have installed the binaries for your Portal nodes and the Deployment Manager. No profiles exist yet on the new servers.
Restore Profiles
In this section, we will restore the backed up profiles onto the new servers.
Restore the Deployment Manager profile
- Copy the backed up DMGR profile to some location on your new Deployment Manager server. In my example, my backup file was dmgrProfileBackup.zip.
- Restore the DMGR profile by executing the following command from the <dmgr's AppServer root>/bin directory:
Windows: manageprofiles.bat -restoreProfile -backupFile <full path to DMGR zip file>
Linux/UNIX: ./manageprofiles.sh -restoreProfile -backupFile <full path to DMGR zip file>
For example:
./manageprofiles.sh -restoreProfile -backupFile /opt/WPBackups/dmgrProfileBackup.zip
NOTE: After this completes, do not start the DMGR server yet. There is still more configuration to do after all profiles are restored.
For me, this process took less than a minute.
Restore the Primary Portal Node profile
- Copy the backed up Primary Portal Node profile to some location on your new Primary Portal Node server. In my example, my backup file was wpProfile1Backup.zip.
- Restore the Primary Portal Node profile by executing the following command from the <wp_profile's AppServer root>/bin directory:
Windows: manageprofiles.bat -restoreProfile -backupFile <full path to Primary Portal Node zip file>
Linux/UNIX: ./manageprofiles.sh -restoreProfile -backupFile <full path to Primary Portal Node zip file>
For example:
./manageprofiles.sh -restoreProfile -backupFile /opt/WPBackups/wpProfile1Backup.zip
NOTE: After this completes, do not start the nodeagent or WebSphere_Portal server(s) yet. There is still more configuration to do after all profiles are restored.
For me, this process took a little over a minute.
- Edit the <PortalServer root>/wps.properties file and add the following lines to it:
ProfileName=<your profile name>
ProfileDirectory=<your profile directory>
For example:
ProfileName=wp_profile
ProfileDirectory=/opt/IBM/WebSphere/wp_profile
Restore Additional Portal Node profile
- Copy the backed up Additional Portal Node profile to some location on your new Additional Portal Node server. In my example, my backup file was wpProfile2Backup.zip.
- Restore the Additional Portal Node profile by executing the following command from the <wp_profile's AppServer root>/bin directory:
Windows: manageprofiles.bat -restoreProfile -backupFile <full path to Additional Portal Node zip file>
Linux/UNIX: ./manageprofiles.sh -restoreProfile -backupFile <full path to Additional Portal Node zip file>
For example:
./manageprofiles.sh -restoreProfile -backupFile /opt/WPBackups/wpProfile2Backup.zip
NOTE: After this completes, do not start the nodeagent or WebSphere_Portal server(s) yet. There is still more configuration to do after all profiles are restored.
- Edit the <PortalServer root>/wps.properties file and add the following lines to it:
ProfileName=<your profile name>
ProfileDirectory=<your profile directory>
For example:
ProfileName=wp_profile
ProfileDirectory=/opt/IBM/WebSphere/wp_profile
- Repeat these steps for each additional node in your environment.
Restore Additional Files
If you had any files stored outside of the profile file structure that you need for your Portal, copy those over to each server. This would include any custom jar files and database drivers, for example.
Restore Databases
Again for this guide, DB2 V9.7 was used as the backend database. If you are using Oracle or SQLServer, work with your DBA to properly restore the databases. For my installation, I used the same database server as my source environment, and followed these steps:
- Log in to the database server as the Database Administrator
- Execute the following command for each database:
db2 RESTORE DATABASE <db_name> FROM <backup directory> INTO <new database name>
For example:
db2 RESTORE DATABASE reldb FROM /home/db2inst1/DBbackups/reldb INTO reldb2
Checkpoint 3
At this point, the profiles and databases have been restored. However, the profiles are still referencing the original host names, and the new Portal is not connected to the restored databases yet, so the Portal Cluster is still not usable.
Update Hostname and NodeName
In this section, we will update the hostname and nodename configuration for the DMGR and Portal profiles. Updating the hostname is
required. Updating the nodename is optional.
Updating the DMGR HostName and NodeName
- From the <dmgr_profile>/bin directory, execute this wsadmin command to change the hostname for the DMGR:
Windows: wsadmin.bat -c "$AdminTask changeHostName {-nodeName myDmgr -hostName newdmgr.ibm.com}” -conntype NONE
Linux/UNIX: ./wsadmin.sh -c "\$AdminTask changeHostName {-nodeName myDmgr -hostName newdmgr.ibm.com}” -conntype NONE
where "myDmgr" is your DMGR's node name and "newdmgr.ibm.com" is your new hostname.
- Start the DMGR on this server by executing the following command from the <dmgr_profile>/bin directory:
Windows: startManager.bat
Linux/UNIX: ./startManager.sh
- This step is optional. Change the node name of your Deployment Manager by following these steps:
- From the <dmgr_profile>/bin directory, execute this wsadmin command to change the nodename for the DMGR NODE:
Windows: wsadmin.bat -user <dmgr admin user> -password <dmgr admin pwd> -c "$AdminTask renameNode {-nodeName myDmgr -newNodeName newDmgr}"
Linux/UNIX: ./wsadmin.sh -user <dmgr admin user> -password <dmgr admin pwd> -c "\$AdminTask renameNode {-nodeName myDmgr -newNodeName newDmgr}"
where "myDmgr" is your old node name and "newDmgr" is your new node name
- Edit the <dmgr_profile>/bin/setupCmdLine.bat (Windows) or setupCmdLine.sh (Linux) file and ensure that the WAS_NODE value is set to your new node name:
Windows: SET WAS_NODE=newDmgr
Linux: WAS_NODE=newDmgr
- Restart the DMGR.
Updating the Primary Portal Node Hostname and NodeName
- Edit the <wp_profile>/properties/wsadmin.properties and make sure the following properties are set correctly for your new DMGR hostname:
com.ibm.ws.scripting.host=newdmgr.ibm.com
com.ibm.ws.scripting.port=8879
- From the <wp_profile>/bin directory, execute the following wsadmin command to change the hostname for the Portal Node:
Windows: wsadmin.bat -user <dmgr admin user> -password <dmgr admin pwd> -c "$AdminTask changeHostName {-nodeName myWpNode1 -hostName newwpnode1.ibm.com}"
Linux/UNIX: ./wsadmin.sh -user <dmgr admin user> -password <dmgr admin pwd> -c "\$AdminTask changeHostName {-nodeName myWpNode1 -hostName newwpnode1.ibm.com}"
where "myWpNode1" is your actual Portal node name and "newwpnode1.ibm.com" is the new Portal hostname.
Note: This process will connect to the DMGR and update the hostname in the DMGR master configuration.
- This step is optional. Change the Portal node's node name by following these steps.
- From the <wp_profile>/bin directory, execute this wsadmin command to change the nodename for the Portal Node in the DMGR configuration:
Windows: wsadmin.bat -user <dmgr admin user> -password <dmgr admin pwd> -c "$AdminTask renameNode {-nodeName myWpNode1 -newNodeName newWpNode1}"
Linux/UNIX: ./wsadmin.sh -user <dmgr admin user> -password <dmgr admin pwd> -c "\$AdminTask renameNode {-nodeName myWpNode1 -newNodeName newWpNode1}"
where "myWpNode1" is the old node name and "newWpNode1" is the new node name.
- From the <wp_profile>/bin directory, execute this wsadmin command to change the nodename for the Portal Node in the local configuration:
Note: This step is necessary because synchronization will not work when the local node name differs from what is stored in the DMGR configuration:
Windows: wsadmin.bat -c "$AdminTask renameNode {-nodeName myWpNode1 -newNodeName newWpNode1}" -conntype NONE
Linux/UNIX: ./wsadmin.sh -c "\$AdminTask renameNode {-nodeName myWpNode1 -newNodeName newWpNode1}" -conntype NONE
where "myWpNode1" is the old node name and "newWpNode1" is the new node name.
- Edit the <wp_profile>/bin/setupCmdLine.bat (Windows) or setupCmdLine.sh (Linux) and ensure that WAS_NODE is set to your new node name:
Windows: SET WAS_NODE=newWpNode1
Linux/UNIX: WAS_NODE=newWpNode1
- Edit the <wp_profile>/ConfigEngine/wkplc.properties file and ensure these two properties are accurate:
WasRemoteHostName=newdmgr.ibm.com
WpsHostName=newwpnode1.ibm.com
- Restart the DMGR to ensure the new configuration is loaded.
- Synchronize the node using the syncNode command from the <wp_profile>/bin directory:
Windows: syncNode.bat newdmgr.ibm.com 8879 -user dmgrAdmin -password dmgrPassword
Linux/UNIX: ./syncNode.sh newdmgr.ibm.com 8879 -user dmgrAdmin -password dmgrPassword
Updating Additional Portal Node Hostnames and NodeNames
Repeat the Primary node steps in the previous section for each additional node. If you'd prefer, you can save the steps to restart the DMGR and synchronize the nodes until all Portal nodes have been updated.
Update WCM Variables with the new hostnames and nodenames
- Start the Deployment Manager and nodeagents for each node. Do not start WebSphere_Portal on any node yet.
- Log in to the Deployment Manager
- Navigate to Environment -> WebSphere Variables
- Set the Scope to your first WebSphere_Portal server
- Edit the WCM_HOST variable to be the new hostname of that Portal server.
- Repeat steps 4-5 for each WebSphere_Portal server (horizontal and vertical) in your cluster.
- If you changed the Node Name, then:
- Still in the WebSphere Variables, set scope to your primary Portal node.
- Edit the WAS_NODE_NAME variable and set the new node name.
- Repeat steps 7 for each Portal node in your cluster.
- Save all changes and synchronize the nodes.
Checkpoint 4
At this point, your new cluster is installed and the profiles have been restored. The hostnames and node names have been updated as needed in the WebSphere configuration. The Deployment Manager and nodeagents should be functional at this point, and you should be able to synchronize the nodes. The WebSphere_Portal servers are NOT functional yet, so do not start those servers. WebSphere Portal is still pointing to the original database, so we still need to connect it to your new databases.
Connect the new Portal environment to the database
- On the primary node, edit the wkplc_DbDomain.properties file and make any necessary changes to the following properties for the domain, where domain is release, community, customization, jcr, likeminds, and feedback:
domain.DbName
domain.DbURL
domain.DbSchema
domain.DbUser
domain.DbPassword
domain.DataSourceName
domain.DbRuntimeUser
domain.DbRuntimePassword
- On the primary node, edit the wkplc_DbType.properties and ensure that the following property for your db_type is still valid, where db_type is db2, oracle, sqlserver, db2_zos or derby. :
db_type.DbLibrary
- On the primary node, execute the following ConfigEngine script from the <wp_profile>/ConfigEngine directory to ensure the new properties are valid:
Windows: ConfigEngine.bat validate-database-connection -DWasPassword=<dmgr password>
Linux/UNIX: ./ConfigEngine.sh validate-database-connection -DWasPassword=<dmgr password>
- On the primary node, execute the following ConfigEngine script to update the database configuration:
Windows: ConfigEngine.bat connect-database -DWasPassword=<dmgr password>
Linux/UNIX: ./ConfigEngine.sh connect-database -DWasPassword=<dmgr password>
- On each secondary node, copy the wkplc_DbDomain.properties and wkplc_DbType.properties files over from the primary node.
- On each secondary node, ensure that the db_type.DbLibrary property is valid for that node.
- On each secondary node, execute the following ConfigEngine script to ensure that the database information is accurate for the local JCR configuration:
Windows: ConfigEngine.bat action-update-icm-properties -DWasPassword=<dmgr password>
Linux: ./ConfigEngine.sh action-update-icm-properties -DWasPassword=<dmgr password>
- Restart the DMGR, nodeagents, and WebSphere_Portal servers to complete the configuration.
Checkpoint 5
At this point, your WebSphere Portal server in your cluster is ready for use. The new Portal server is identical to your source Portal, but is now using its own database and is completely separate.
Web Server considerations
If you have configured a web server in your source environment, then additional steps need to be taken. We still need to reinstall the web server and plugin though. This section of the guide uses the custom repository we created earlier but you can install these packages from any valid repository.
IMPORTANT: If your webserver definition is NOT on the same node as the DMGR node or Portal nodes, then you must also update its hostname in the WAS config by executing this wsadmin command from the webserver's node:
Windows: wsadmin.bat -user <dmgr admin user> -password <dmgr admin pwd> -c "$AdminTask changeHostName {-nodeName webServerNode -hostName newwebserver.ibm.com}"
Linux/UNIX: ./wsadmin.sh -user <dmgr admin user> -password <dmgr admin pwd> -c "\$AdminTask changeHostName {-nodeName webServerNode -hostName newwebserver.ibm.com}"
In my case, the webserver was defined in the WAS configuration on my primary Portal node, so hostname updates for it were completed in the primary portal node section of this guide.
- Copy the custom repository to the target server, or map/mount a drive to the custom repository so that the target server can access it.
- Install IBM Installation Manager by launching the installer from the <custom repository>/IIM/<os_type> directory:
Windows: installc.exe -acceptLicense
Linux/UNIX: ./installc -acceptLicense
Note: This command silently installs IBM Installation Manager as an administrative user. If you would prefer to install it using a graphical installer, then use the "install.exe" or "install" files instead. It is entirely up to you.
- Launch IBM Installation Manager from the <InstallationManager root>/eclipse directory:
Windows: IBMIM.exe
Linux/UNIX: ./IBMIM
- Go to Files -> Repositories and click Add
- Enter the path for your <custom repository>/repository/repository.config file, for example:
/opt/media/WP8001Clone/repository/repository.config
- Click OK to save changes.
- On the Installation Manager launch screen, click Install.
- On the Packages screen, check the boxes to install IBM HTTP Server, WebSphere Plugin and WebSphere Customization Toolbox.
- I kept defaults for all screens. When the installation finishes, launch the WebSphere Customization Toolbox and select "Web Server Plug-ins Configuration Tool"
- Add a plugin named the same name as the webserver in your source environment. In my case, this was "webserver1"
- Click 'Create' and follow the rest of the screens to create the webserver plugin.
NOTE: Normally after this completes, you would copy the "configurewebserver1" script over to your Deployment Manager to configure the webserver definition in the WAS conifguration. Because we have cloned the environment, this is already done, so running the "configurewebserver1" script is not needed.
- Exit the WebSphere Customization Toolbox and IBM Installation Manager.
- Log in to your Deployment Manager and navigate to Servers -- Server Types -- Web Servers
- Check the box next to your web server and click "Generate Plug-in"
NOTE: This will be written to the <dmgr_profile>/config/cells/<cellname>/nodes/<nodename>/servers/webserver1/plugin-cfg.xml file.
- Copy the plugin-cfg.xml file to the Plugin server into the <Plugin root>/config/webserver1 directory, where "webserver1" is the name of your webserver definition.
- Restart the webserver.
Conclusion
At this point, you have completed cloning your WebSphere Portal v8 cluster. It should be functional and ready for use. It will be completely identical to the configuration of the source Portal cluster.
As a next step, you might consider scripting together functions in this guide. It will make the process easier, especially considering the limitations of using the same installation paths, and knowing what the original node names were in order to change the hostnames. Otherwise, make sure you note what the original installation paths and node names were and keep that with your cloned backup image.