Configuring for Multiple Sites

You can improve loading for multiple sites by using the binary update configuration. In this configuration you run all core related operation on only one site (the master site) and other sites receives a binary update from the MASTER site. This greatly reduces the overall loading time.

You can also use the clone configuration in this set up to improve the initial loading time of the system. In this case, the load of all initial bundles is done on the master site and the rest of the sites clone the data from the master site.

To support this configuration, the SitesDescriptor.xml file has an attribute named siteUpdateType. The master site has the master attribute in this file set to YES and the siteUpdateType attribute set to TEXTUAL. All remote sites have the siteUpdateType attribute set to BINARY. For example:

In this example, the Runtime-Site1 site is the master site and Runtime-Site2 is a binary update supported site. The following figure shows how you would configure update for N number of sites:

When you run the Deploy Collection task in this case, the task automatically clones any new segments to all binary sites. Any further updates on that segment are also cloned. When you use the task to re-index the data, all re-indexing is done only on the master site and cloned to the binary sites. This greatly improves re-indexing time.

In this case the TAL process is started using the TransfomManagment task, which triggers the PublishToPreviewPreparation and PublishToPreview tasks. PublishToPreview loads data on the master site as a textual update.

All core operations such as insert and index run only on the master site. The master site uploads a delta packet with binary updates of the updated repositories. Sites configured as siteUpdateType="BINARY" download the delta packet along with regular update packets. No core operations are performed on binary update sites. They just import the deltas received. Loading on binary sites is much faster than textual sites, since no core operations are performed. It is recommended that this approach be used for incremental loading only.

In this case the TAL process is started using TransformMgmtInitialLoad which triggers the PublishToPreviewPreparation and PublishToPreview tasks. In initial load mode, PublishToPreview loads data to the Publication Manager and stops.

Once all initial bundles are transformed and loaded to Publication Manager, run the P2RTInitialLoad task which triggers the Publish2RT task once for each collection. Publish2RT loads data on the master site as a textual update and on binary supported sites as a binary update. This approach is faster than regular approach.

• Initial load approach using the TransformMgmtInitialLoad and P2RTInitialLoadToMaster tasks with full clone using the FullCloneFromMaster task

Once all initial bundles are transformed and loaded to Publication Manager, run the P2RTInitialLoad task which triggers the Publish2RT task once for each collection. Publish2RT loads data only on the master site. No data is loaded on the binary sites. Once the Publish2RT completes, the master site is loaded and available for use.

Next run the FullCloneFromMaster task. This task creates a full clone packet from the master site, uploads the packet to a common shared location ${package.destination.folder}, and triggers a CloneToSite task for each binary site. The CloneToSite task downloads the full clone packet and deploy it on the site. In this case, each binary site is loaded in parallel and available for use independently.

The data directory structure of all sites must be the same. If a binary site’s directory structure is different from the master site, use symbolic links to point to any directories not in the expected structure and configure that in the 3C.properties and setEnv.sh/bat files.