Rehosting
Rehosting is the process by which data is migrated from one server to another. This section provides an example of how to move data from a monolithic environment to a split configuration, or cluster environment.
To rehost a server the following must be done:
• Before you begin, a cluster or split configuration environment must be configured.
• The Publisher must be migrated from the monolithic server to the hosting server.
• The Publisher must be configured, by running the Deploy Collection command.
• Data must be migrated from the monolithic server to the cluster or split configuration Viewers.
Before You Begin Rehosting
Before you begin this procedure ensure the following:
• There are no Servigistics InService tasks running, queued, paused, or in a failed state.
• A monolithic system exists with data to be moved.
• There exists a previously configured cluster or split configuration server, with no data on it.
Migrating the Publisher
To migrate the Publisher from the monolithic server to the cluster or split configuration Publisher use the following procedure:
1. Copy the entire Global file system from the monolithic server to the cluster or split configuration Publisher. This directory can be found by navigating todata/Storages/Global/.
2. Copy all <FamilyName>_TR directories to the cluster or split configuration Publisher. This directory can be found by navigating todata/Storages/.
3. Export the following E3C schemas to the Publisher:
◦ TN_CM_SOURCES
◦ TN_CM_FOLDERS (first delete existing content)
◦ TN_CM_ADMIN_TREE
◦ TN_CM_FEED
◦ TN_GN_SEQUENCES
◦ SC_IDENTITY
◦ SC_REGISTRY
◦ SC_RELATIONS
4. Navigate to config/System/config/ and copy PublicationList.xml to the cluster or split configuration Publisher.
5. Navigate to config/System/config/ and copy ProfileDefinitions.xml to the cluster or split configuration Publisher.
6. Copy the following directory to the new cluster or split configuration Publisher: work/Application/ContentManger/Work/Profiles.
7. Restart the Publisher.
Configure the cluster or split configuration Publisher
Following the migration of the Publisher you must configure the cluster or split configuration Publisher by using the following procedure:
1. Bring up the new Publisher and all Viewers.
2. Run Deploy All Collections for all families that you copied to the Publisher.
Migrating Data to the Viewers
To migrate data to the cluster or split configuration Viewers use the following procedure:
1. On each Viewer delete all content from the Storages directory.
2. From the monolithic server copy all data from Storages/<SegNumber>/directory to the same directory on the cluster or split configuration Viewers, with the exception of the following directories, which should NOT be copied:
◦ Global
◦ *_TR
3. On each Viewer delete all content from the following Core directories.
◦ Core/{Viewer1-hostname}/coreServer-1
◦ Core/{Viewer1-hostname}/coreServer-2
4. From the monolithic server copy the following directories to the same directory on the cluster or split configuration Viewers:
◦ <Servigistics InService>/data/Titles/<segName>_<number>/Data/Core
◦ <Servigistics InService>/<segName>_Secondary_<number>/Data/Core
5. On the CMI database delete the contents of the following tables from the monolithic server and then copy them to cluster or split configuration Viewers:
◦ TN_CM_SOURCES
◦ TN_CM_FOLDERS
◦ TN_CM_ADMIN_TREE
◦ TN_CM_FEED
6. On the E3C database delete the contents of the following tables from the monolithic server and then copy them to cluster or split configuration Viewers:
◦ TN_GN_SEQUENCE
7. Migrate the entire TitanDB and TitanDB2 databases from the monolithic server to cluster or split configuration Viewers.
8. Restart the Viewers.
Rehosting a Monolithic Installation on the Same Path
1. Install Servigistics InService on the target server at the same location as the source server.
2. Apply customizations.
3. Back up and restore CMI, E3C, TITAN, and TITAN2 databases from the source to the target.
4. Perform the following SQL query to update the DNS in the WINDCHILL schema if it differs in the source and the target.
update fvhost set hostname='target.ptcnet.ptc.com'
where hostname='source.ptcnet.ptc.com';
update repository set lastknowndomain='target.ptcnet.ptc.com'
where lastknowndomain='source.ptcnet.ptc.com';
update site set URL='http://target.ptcnet.ptc.com:8080/InService/servlet/WindchillGW'
where URL='http://source.ptcnet.ptc.com:8080/InService/servlet/WindchillGW';
5. On the target server, save the directory name of InS_Data\Work\System\Work\CoreCMI_[server_name] and InS_Data\Work\System\Work\Core\[server_name].
6. Copy the Ins_data folder from the source to the target server at the same target location.
a. Rename InS_Data\Work\System\Work\CoreCMI_[source_server_name] to InS_Data\Work\System\Work\CoreCMI_[target_server_name] as mentioned in step 5.
b. Rename InS_Data\Work\System\Work\Core\[source_server_name] to InS_Data\Work\System\Work\Core\[target_server_name] as mentioned in step 5.
7. Copy the InS_SW\Config folder from the source to the target server at the same target location.
8. Start the target services.
Migrating MongoDB from One Host to Another
To migrate MongoDB from one host to another, perform these steps:
1. Stop the MongoDB process that is running.
2. Copy the contents from the <InS_HOME>\InService\Mongo\data\db folder to the target machine location, where MongoDB is installed (<InS_HOME>\InService\Mongo\data\db).
3. Point the database path to the new copied directories in the mongod.conf file on the re-hosted machines.
Migrating Derby database from One Host to Another
To migrate Derby database from one host to another, copy the Derby folder from the \InS_SW\SW\System\DB folder on the source machine to the \InS_SW\SW\System\DB folder of the rehosted environment. This ensures that the Publisher's Derby database is copied to the rehosted Publisher environment and Viewer's to the rehosted Viewer environment. For example:
• P’ > P
• V1’ > V1
• V2’ > V2