Administering a Local Cache Vault
You can specify one vault in a site to act as the local cache vault for the File Server site.
To enable the local cache function in a vault, select a vault type of Cache vault from the Vault type list when you create or update a vault in the File Server site.
Establishing Mirroring in the Local Cache Vault
When you define mounts that associate hosts and folders on the File Server site that holds the local cache vault, you can create a backup to protect against data loss. You can associate each writable local cache vault folder with a backup storage location that mirrors it by specifying the mount paths for folders and the backup storage location in the same entry. If data loss of data occurs in a readable folder, you can copy the data in the backup storage location to the readable folder.
To configure the backup:
1. In the Vault Configuration window, select the readable folder and then select > .
2. In the Root Path field, enter the two paths separated by a semicolon in the following format:
<path to folder that should be read from and written to normally>;<path to folder that mirrors the content>
3. Duplicate the mounts on all the hosts in the File Server site, providing paths to the same physical folders.
4. Select the readable folder in the Vault Configuration window, select > . Select the Enabled checkbox and then click OK.
Setting the Preferred Content Cache Site
To benefit from the technology described in this chapter, users must set their content cache site preference to the File Server site that includes the local cache vault. Because this is a personal preference that can easily be changed, consider explaining the benefits of this setting and location of the local cache vault to users. The online help for your Windchill solution provides further information about accessing and setting user preferences.
Content Replication from Local Cache to the Main Site
Content is replicated from the local cache vault to the main vault through an automatic synchronization process that runs every 3 hours by default. You can also perform a sysForceSync operation manually. To change the frequency of the automatic synchronization process or perform a sysForceSync operation, use JConsole. You can also use JConsole to view information about completed synchronizations, including completion time, number of runs, number of items moved, and number of items not moved due to errors.
Removing Unreferenced Files from a Cache Vault on a File Server Site
An unreferenced file is a content file that no longer has a valid association to a Windchill object. For example, a file is no longer referenced when all objects to which it was associated have been deleted, or when a user deletes the association to the file when updating the object.
The following procedure describes the process for removing files that are no longer referenced in Windchill from a cache vault on the File Server site. This procedure also removes references to replicated content that was uploaded to the File Server site through an upload to a replica cache. This procedure does not apply to any existing replication rules for the vault. If any of the content uploaded to the replica cache must permanently reside on the File Server site (for the purpose of faster downloads, for example), then you must create replication rules for these objects.
Remove Unreferenced Files from a Cache Vault
To remove unreferenced files from a cache vault:
1. Set the property wt.fv.purgeUnreferencedFilesOlderThan to 60. (The value represents days.)
2. In the Vault Configuration window, select the target vault from which you want to remove unreferenced files and then select > .
A window appears to warn you that files will be removed from your system permanently.
3. Optionally, select the Move files instead of deleting checkbox to move the files to a backup location rather than simply deleting them. It is recommended that you select this checkbox.
4. Click OK.
If you selected the Move files instead of deleting checkbox, the backup files are stored in a folder in the vault mount location whose name includes .unreferenced.
Resetting Replication
Before resetting replication, you must remove unreferenced files by selecting > on the Vault Configuration window. Otherwise, the replication operation fails because it its trying to replicate files that are already present in the vault folder.
To remove all previously replicated content for a target site, select > on the Vault Configuration window. When you do this, all content for which replication rules are defined will be replicated during the next scheduled replication operation. The File Server site may still contain content that has been uploaded to its cache, and references to this content are not removed. Use this option with extreme caution before the site is scheduled to be unregistered.
Resetting Undelivered Replication Items
When replication finishes, the a message appears to indicate that delivery is complete. This message means that the main site has successfully sent a message to the File Server site, but it does not guarantee that replication was executed successfully on the File Server site.
If a “Failed to Replicate” message appears, select the target vault on the Vault Configuration window and select Reset Undelivered Replication Items, then schedule the replication again.
Selecting Reset Undelivered Replication Items removes references to the replicated content that did not replicate properly previously. These references are deleted automatically after a period of 2 days during the execution of a replication job, but you can use this option to replicate failed content again sooner.
Predictive Replication
Predictive replication is a feature that enables Windchill to preemptively determine the content that is required at a File Server site based on patterns of user behavior. Predictive replication replicates future iterations of an object without an explicit replication schedule set by a user or administrator. You can enable or disable this feature with the wt.fv.predictiveReplicationEnabled property. By default, the property is set to true, indicating that predictive replication is enabled.
The following conditions cause a predictive replication schedule to be set up automatically:
• A user has set the site preference to a File Server, but the content that the user requested is has not been replicated to the preferred site through a scheduled replication. In this case, the content is dynamically replicated and a predictive replication schedule is set.
• The user uploads the content to the preferred site.
Creating New Rules
The system creates a special rule for predictive replication and then replicates the objects that the special rule applies to. These rules are hidden from users.
After the creation of this special rule, if a schedule does not already exist for a replica vault, a recurring predictive replication schedule is created. This predictive replication operation runs daily at a specific time specified in the wt.properties file. The scheduleType of this schedule is named:
PREDICTIVE
The schedule performs replication only for objects that qualify for the special predictive replication rule or scheduleType, such as the following:
PREDICTIVE+SCHEDULED
This schedule performs replication for both a predictive replication rule and the normal rule.
 |
Only one predictive replication schedule can exist for each vault.
|
Before this special rule and schedule are created, the system determines whether a schedule for that vault exists. If a schedule exists, the system determines whether a replication rule already exists for the object class and the vault. If both a schedule and a replication rule already exist, then a predictive replication rule and schedule are not created.
As a part of predictive replication, all objects are replicated to a vault that is designated as the cache. This depends on the value that was set in the ad hoc replication property.
Cleaning Up Expired Rules
When the method server starts, the expired predictive replication rules are automatically cleaned up. The cleanup schedule has a default frequency of 1 day, which means that the cleanup operation happens every day.
The expiration of predictive replication rules is determined by the following property:
wt.fv.predictiveReplicationDuration
This property determines the duration for which the predictive replication rules run, and the unit of measure is days. The default value is 90 days.
The expiration date of a predictive replication rule is determined based on the creation date of the rule and the duration set in the wt.fv.predictiveReplicationDuration property. If the property is set to 90 days and a rule was created more than 90 days ago, the rule is considered expired and is deleted during the cleanup process.
Preferences and Options
The following properties in the wt.properties file define predictive replication preferences and options:
|
Property
|
Description
|
|---|---|
|
wt.fv.predictiveReplicationDuration
|
The duration, in days, for which the replication rule that runs predictive replication rule runs. This is an organization-level preference. The default value is 90 days.
|
|
wt.fv.predictiveReplicationEnabled
|
Determines whether predictive replication is enabled or disabled. By default, the property is true, meaning that predictive replication is enabled. To disable predictive replication, set this property to false.
If you disable predictive replication and then enable it again, the system performs predictive replication to replicate future iterations of content that is accessed after the property is set to true. Content that was accessed while predictive replication was turned off is not replicated.
|
|
wt.fv.predictiveReplicationAllIterations
|
Determines whether to replicate all iterations or only the latest iteration. The default value is false, indicating that only the last iteration is replicated. To replicate all iterations, set this property to true.
|
|
wt.fv.predictiveReplicationAllVersions
|
Determines whether to replicate all versions or only the current version. The default value is false, meaning that only the current version is replicated. To replicate all versions, set this property to true.
|
|
wt.fv.predictiveReplicationPeriodicity
|
Specifies how frequently, in days, replication should occur. The default value is 1 day.
|
|
wt.fv.predictiveReplicationScheduleTime
|
Specifies the time for scheduling in the following format: HH:MM:SS. The default value is 00:00:00.
|
Ad Hoc Replication
Ad hoc replication means the copying of content from a main site to a Windchill File Server when the content is not available on a remote site and the user has set preferences to a Windchill File Server.
If a user attempts to download data that does not exist on the local File Server, the content is retrieved from the nearest proximity site that has the data and is also replicated to the local File Server. The next time another local user downloads the same document, it is retrieved directly from the local File Server.
When ad hoc replication occurs, predictive replication rules and schedules are created.
You can control ad hoc replication by setting the wt.fv.master.adhocCaching.flag property in the wt.properties file. This property can have the following values:
• 0—Ad hoc replication is disabled.
• 1—Ad hoc replication is enabled only if a rule exists for the content on a user’s preferred File Server.
• 2—Ad hoc replication is enabled for all conditions. This is the default value.
The wt.fv.master.adhocCaching.ThreadPoolSize property sets the number of concurrent threads that are available for ad hoc replication. The default value for this property is 3.
|
|
Ad hoc replication also works at a main site if it has replica vaults configured.
|
Site Proximity
When creating or editing a site, you can set a list of sites in order of proximity to the new or updated site. During ad hoc replication, the system checks these sites in the order they appear in the list to determine which site the content should be retrieved from. By setting up the site proximity list, you can ensure that user requests are fulfilled as quickly as possible by using the closest site. By default, the main site is added to the end of the list, if it has not already been included in the list in another place in the order.
User-initiated Replication
User-initiated replication enables users to collect and replicate objects that cannot be easily bound together by replication rules. When a user initiates replication, the replication process begins immediately. The replication action is available from the Actions menu on the Search Results table as well as through the row-level Actions menu on the details page for the object.
|
|
For the replication action to appear and for the function to be active, the user must be a member of a Replication Managers group. For more information, see Adding Members to the Replication Managers Group.
|
When the users select the replicate action, the User Initiated Replication window appears. On this window, users must identify target File Server sites to replicate and choose whether to replicate all, required, or no dependents for CAD documents.
|
|
Selecting which dependents to replicate is applicable only to CAD document objects that were selected. For each target CAD document, dependents use the as-stored configuration specification if it exists. If it does not exist, the latest configuration specification is used.
|
After the user initiates the replication action, the following process occurs:
1. The replication job starts in the background. The results of the job (success, failure, and errors) are reported in the Event Management utility.
2. A predictive replication rule and schedule are created to replicate future iterations of the replicated objects.
3. All the objects included in the replication job are replicated to the vault that is the default target for the site.
|
|
Every site must have a vault that is the default target for the site. If a vault that is a default target for a site already exists and you select a new vault, the new vault becomes the default target for the site rather than the existing one.
|
Replication Process
Windchill can perform parallel replication or run replication sessions for several target replica vaults located on any of the sites at the same time. Content that resides on the main site is copied to a target replica vault as determined by replication policy rules. During the replication process, this content is pulled from the main site to the File Server site and stored in the space allocated to the target replica vault.
Replication Process Overview
When a replication job begins, the system completes the following steps:
1. The system gathers content to be moved to File Server location based on the replication rules defined for the replication session.
2. The File Server copies the individual content files and stores them in the replication vault location.
3. When all files are copied and stored successfully, the replication job is marked as either completed successfully or completed with errors. If a job is marked as completed with errors, it means that one or more of the collected items could not be replicated.
Property Controls
To run multiple active sessions of replication concurrently, use the wt.fv.master.Replication.NumOfQueues property. This property defines the number of queues that are used to simultaneously execute replication sessions. The default setting is 1.
Use caution when increasing the maximum number of concurrent sessions, as each session is resource-intensive and uses the network bandwidth at the main site for content transfers.
As more replication sessions are scheduled, they are queued in parallel queues so that at any time, the number of active sessions is equal to or less than the number of queues.
|
|
The queues can be configured to run on a specific method server. This feature provides for another dimension to the scaling of replication activity.
|
Deleting Registered File Servers
Under normal circumstances, a registered File Server cannot be deleted. You can delete a registered File Server only if all of the cached objects in the cache vault of the File Server have been pulled to the main site by a synchronization operation.
In addition, if there are any failed or partial uploads in which the files are uploaded to the cache vault, the File Server cannot be deleted. The system deletes references to these files only after one month during the cleanup process.
Upgrade Considerations
You must set the container reference of the Site container as follows:
• Site object—For all pre-upgrade sites, set the read-only flag to false and the enable flag to true.
• Replica Vault object—For all objects, set the flags to their states before the upgrade.
Moving a File Server to a Different Machine
Use this procedure to move a File Server to a different machine while keeping the vaults.
1. Install the new File Server using a different host name. In the post-installation steps, do not create a new site. However, make sure to copy the public key to the File Server.
For more information about installing File Server, see About the File Server Management Utility.
2. Using the File Server Management utility, take the File Server offline. This ensures that no more downloads or uploads occur on the File Server.
3. Copy the vault folder to the new server.
4. For each vault associated to the File Server, delete the folder MOUNT_VALIDATION_DATA inside each of the folders.
5. Using the Site Administration utility, update the site URL of the previous File Server to point to the URL of the new File Server.
6. Using the Vault Configuration utility, update the host name of the File Server.
7. Using the File Server Management utility, take the File Server online.
8. Using the Vault Configuration utility, update the mount path with new path.
9. Using the Vault Configuration utility, validate all of the File Server folder mounts.
Enhancing the File Server User Experience
The following functions help with the user experience when the File Servers are configured and in use:
• Site Monitor—This is a daemon thread which, at Windchill-defined intervals, pings all File Server sites and holds the ping status in the main site. The following property specifies the interval between each replica ping:
wt.intersvrcom.sitePingIntervalInMinutes
The monitor is present on every method server on the system, and the result of each ping is stored in the cache. Method servers check the ping results before each attempt to ping the File Server sites. If the existing pings are recent enough, they skip the next ping.
• Automatic Mount Validation—This feature, similar to Site Monitor, validates mounts by folder, file, or site. It enables mount validation in clustered environments and on File Server sites.
You can also validate a mount through the Vault Configuration window by selecting an object, such as site, vault, or folder, from the tree in the left pane and then clicking Validate.
|
|
If there is at least one mount that has not been created yet, a warning message appears.
|
When you validate a mount from the Vault Configuration window, the system does the following:
1. The system sends all of the data needed for the mount validation to the File Server site.
2. The system on the File Server site validates all of the existing mounts related to the selected object.
3. The system sends the validation status to the main site.
4. The system on the main site updates the status of all the mounts related to the selected object to Valid or Does not exist.
5. The system updates the Last Status Update Time timestamp for all the mounts related to the selected object.
• Manage quarantined files—You can identify quarantined files, remove files from quarantine, and manage the frequency of quarantine notifications.
Any content that Windchill deems corrupted is marked as quarantined. Quarantined content is content that Windchill has found to be corrupted or defective in some way. This content cannot participate in revaulting or replication until it is removed from quarantine.
For quarantined objects, the folder must be accessible; it is not necessary for the content to be accessible. This helps to avoid quarantining files for folders that are not mounted. When revaulting and replication process take place, quarantined objects are automatically filtered out and not included in the process.
The dedicated property wt.content.QuarantinedContentManager collects data about currently quarantined files or removes a subset of these files from the quarantine.
To generate reports for all quarantined content in the system and store them in a file, use the following command:
java wt.content.QuarantinedContentManager [-reportAllQuarantined][<file>]
To remove the quarantine flag from all content that is currently in quarantine, use the following command:
java wt.content.QuarantinedContentManager [-UnQuarantineAll]
A separate log is also created with a record for each quarantined file. This log includes details about why each object is quarantined.
Windchill administrators can sign up for email notification of quarantined content. The wt.content.QuarantineNotifyIntervalHours property specifies the interval, in hours, at which an administrators who subscribe to the JMX quarantine notification receive a notification of content quarantine events. The default value is 24 hours, which means that a notification about quarantine events is sent out, at most, once in a 24-hour period. If you set the value of this property to 0, a notification is sent out for each quarantined event.
Utility to Assist Backups
You can run a utility at the main site to distinguish between files that are currently copied on both the main site and the File Server site, and other files that have been checked in to the File Server site but have not been copied to the main site. This utility is intended to guide backup processes. You invoke the utility from the command line with the following syntax:
windchill -cp <path_to_codebase>
wt.fv.uploadtocache.CCS_BackupFilesList
wt.fv.uploadtocache.CCS_BackupFilesList
The output of this utility is an ASCII file in the log directory that lists files on File Server sites that are not on the main site. Files are listed by site and by folder within each site. The name of the output file has the following syntax:
ccs_backup_<timestamp>.log