Question & Answer
Question
Cause
Answer
This Case serves as a forum to answer any questions or concerns that arise from the cloning process.
Step 2 – Clone the UCD file system, database, and application data (appdata) folder to a new instance for upgrade testing.
In this step, you create a testing environment by cloning all or most of the production environment. Two approaches to achieve this are:
Approach 1 – Cloning the virtual machine (VM)
If your production server is being hosted on a VM, this approach creates an exact replica of your production server.
1. Stop the production server.
2. Stop the production VM.
3. Clone the production VM.
4. Run the "Cloning the database" section.
5. Run the "Cloning the Application Data (appdata) folder" section.
6. If UCD is configured to use S3 storage (new in 7.0.5.0), clone the S3 bucket if you want to use the same component versions artifacts as the production server. Note: This step can be skipped if you would prefer to create new component version artifacts.
7. Start the production VM.
8. Start the production server.
9. Start the cloned VM.
10. Modify the cloned database per the "Modify the database" section.
11. Modify the appropriate property values in the clone’s installed.properties per the "Modify installed.properties" section.
12. Start the clone server. Note: You need to use the machine IP to access the UCD UI until the "Other considerations" step is complete.
13. Modify the clone per the "Other considerations" section.
Approach 2 – Install a new server and copy some production file system components over to the clone
This approach has you install a brand new UCD server and then populate it with cloned data from the production server. The cloned server is not an exact copy of your production environment, but is similar enough to test an upgrade.
1. Create the clone’s host machine
2. Install the same version of Java™ to it that the production host uses
3. Stop the production server
4. Run the "Cloning the database" section.
5. Run the "Cloning the application data (appdata) folder" section.
6. If UCD is configured to use S3 storage (new in 7.0.5.0), clone the S3 bucket if you want to use the same component versions artifacts as the production server. Note: This step can be skipped if you would prefer to create new component version artifacts.
7. Start the production server
8. Transfer the UCD installation files to the clone host. Place the JDBC driver .jar that production is using into the clone's installer's lib/ext directory so that the same JDBC driver is used by the clone.
9. Run the same UCD version installer as your production server, choosing not to install the database. The installer prompts you to configure UCD to use an application data folder. If you do not use an application data folder, this configuration is corrected in a later step.
10. Replace or exchange the clone’s conf/encryption.keystore with production’s. To handle the differences in encryption keys, you can either replace the clone’s encryption.keystore after installation with the production one, or you can exchange the two using the method detailed here:
11. Modify the cloned database per the "Modify the database" section.
12. Modify the appropriate property values in the clone’s installed.properties per the "Modify installed.properties" section.
13. If you are not using an application data folder, replace the clone's var directory with production's. This replacement copies over files like artifact repository and plugins. Also, edit the server's installed.properties file and change the server.appdata.dir value to ".." (Ex: "server.appdata.dir=.."). You can delete the application data folder that was created during the installation because the server does not use it.
14. Start the clone server. Note: You need to use the machine IP to access the UCD UI until the "Other considerations" step is complete.
15. Modify the clone per the "Other considerations" section.
Cloning the database:
Contact your database administrators (DBAs) to clone the database. Your DBA needs to take a backup of the existing database and restore it to a new database that can be accessed from the newly cloned UCD server machine. If more assistance is needed than your DBA can provide, use your placeholder case for assistance.
Cloning the application data (appdata) folder:
Older installs of UCD might not have an application data (appdata) folder. To determine whether you are using an application data folder:
1) Open the server's installed.properties file.
2) Find the following property: server.appdata.dir
3) If the value of that property is "..", then you are not using an application data folder. If the value is not "..", then you are using an application data folder.
Most application data folders are mount points to an external file system. If your application data folder is external to the UCD server, clone the application data folder. Point your cloned UCD server to the cloned application data folder. You do not want your cloned server to use the same application data folder as your production server.
If your application data folder is large and you do not want to clone it for your test environment, you can skip cloning the application data folder and start new. If you chose not to clone the application data folder, no production component versions can be used nor can you view any production step output (both are stored in the application data folder). New component versions must be created to deploy.
If you choose not to clone the application data folder, other application data folder files you might want to copy over are:
a) Custom email notification templates if you want to test them after you upgrade the clone.
b) The plugins directory.
c) Patches. If you want to verify the clone's health before you perform an upgrade, copy the patches. During an upgrade, UCD turns off any patches by appending ".off" to the patch name.
Modifying the database:
1) For High Availability (HA) configurations only:
a) Remove the JMS cluster configuration from the database. This removal requires deleting all the contents of the ds_network_relay table. If you need assistance deleting the contents, contact your DBA.
b) Remove the Web Cluster configuration from the database if applicable. This removal requires deleting all the contents of the ds_server table. If you need assistance deleting the contents, contact your DBA. NOTE: Web clustering is new in 7.0.0.0. Older versions of UCD do not have a ds_server table.
2) To stop automatic component version imports, run the following SQL to update the components in the database:
update DS_COMPONENT set IMPORT_AUTOMATICALLY='N' where IMPORT_AUTOMATICALLY='Y';
The following properties need to be modified to the values that are appropriate for the cloned server:
- hibernate.connection.url – the escaped value of the url of the cloned database
- hibernate.connection.username – the value of the username used to access the cloned database
- hibernate.connection.password – the password of the user used to access the cloned database. NOTE: The password is stored in plain text until the cloned server is started. Once the cloned is successfully started, the password is then encrypted. In later versions of UCD, this value is stored in the secured-installed.properties file.
- server.external.web.url – the escaped value of the url of the cloned server
- server.bucket - made up value
- install.server.web.host - the hostname of the clone server.
- server.appdata.dir - set this property to the location of the cloned application data folder. If you do not use an application data folder, set it to ".." (For example: "server.appdata.dir=..")
- agentcomm.uri (new starting in UCD 7.0) - update the hostname with the clone's.
- encryption.keystore.alias - update only if you copied the encryption.keystore from production to the clone (set it to the same value as the production server's value).
If you are using S3 storage, you might need to modify the S3 storage properties, or ensure they are correct for your cloned S3 bucket:
- codestation.s3.bucket – the bucket name
- codestation.s3.region – the region
- codestation.s3.user – the API key
- codestation.s3.url – custom Url
- codestation.s3.signerOverride – signature algorithm
- codestation.s3.enablePathStyleAccess – true or false
- codestation.s3.password – API secret
Other considerations:
1) From Settings > System Settings in the UI after you start the clone:
a) Set the External Agent URL and External User URL.
b) Remove the license server information
c) Remove the Mail Server Settings information
2) Delete any scheduled jobs from the Calendar.
3) Create new agents for testing. Although production agent information exists in the cloned database, the production agents show offline in the clone because the agents are configured to connect only to the production server. If you want to test deployments after you upgrade, you need to create new agents for the cloned environment.
4) To license the clone, contact your IBM sales representative to obtain a temporary license.
Was this topic helpful?
Document Information
Modified date:
10 March 2020
UID
swg21694427