WebSphere Commerce search server: Managed configuration

The WebSphere Commerce search server can be deployed in the managed configuration. The managed configuration is a variation of the advanced configuration, but contains streamlined configuration tasks.

Note: APAR JR52668 is required to set up the WebSphere Commerce search server in the managed configuration.

Managed configurations are Solr home templates that can be managed by the deployment manager. The templates can be for master, subordinate, and repeater servers. An input loading property file is used to generate the different templates and configure replication. The WebSphere Application Server Deployment Manager is used to perform partial EAR updates. Then, all the managed nodes are synchronized with the managed Solr templates. Optionally, you can configure the managed repeater and subordinate index cores to perform index validation during replication before packaging and deploying the search server.

The following topologies are typical in the managed configuration, where all managed production Solr cluster members are federated and managed by a deployment manager:

1 Managed production Solr cluster with only a number of Solr subordinate servers: Indexing is performed on the staging server, based on the content from the staging database. Typically there are daily full index builds, with partial refreshes performed throughout the day.; Once the index content is verified on the staging server, it is propagated and pushed into each of the subordinate servers using the IndexProp command and index replication.; The subordinate servers are not configured to automatically pull based on predefined intervals. Instead, they fetch the index only from the master once the IndexProp command is triggered. This timing is used because the index on the master server might not always be ready for replication.; This topology is applicable for sites that do not need to index production data such as Inventory, and do not need to perform emergency fixes. That is, a site that does not use an authoring environment or workspaces.
2 Managed production Solr cluster with a dedicated Solr master server, and a number of Solr subordinate servers: Indexing is performed based on the production database, typically with daily full index builds. Once indexing is complete, a test query is run to validate the index content before it is ready to be replicated to subordinate servers.; The managed master server on production is configured as an indexing server and does not serve traffic. This behavior is set by assigning a server weight of 0 in the deployment manager. As a result of the differing roles, the caching configurations of the master server differ from the configurations on the subordinate servers.; To avoid triggering replication while indexing is in progress, it is recommended to block all replications from the master until the index is built and verified. Predefined pull intervals can be used to avoid manually starting index replication on each of the subordinates servers.; It is recommended to perform index builds during off-peak times, as the indexing is based on the production database. Doing so ensures that transaction operations on the database are not negatively affected.; This topology is applicable for sites that need to index production data such as inventory, but do not necessarily need to preview the changes in the staging server.
3 Managed production Solr cluster with a dedicated Solr repeater server, and a number of Solr subordinate servers: Indexing is performed on the staging server, based on the content from the staging database. After the index content it is tested, it is pushed to the Solr subordinate (repeater) server. The repeater's typical role is to index off the production database and store a snapshot of the production index; it does not serve traffic. The subordinate servers are typically configured to automatically pull from the repeater.; This topology is applicable to clients who need to preview changes on the authoring server and perform frequent index builds during the day, including emergency fixes. This topology includes indexing production data.

The following table summarizes the roles that are maintained in each managed topology, and helps you select the topology that best suits your business needs:

Managed topologies
Topology	Repeater	Master	Subordinate
1	A repeater is not used in this topology.	Resides in staging. Performs full and partial indexing off the staging database throughout the day. Is a non-managed node. Cannot perform emergency fixes. Does not serve site traffic. Can preview index data before replication.	Resides in Production. Replication is pushed. It is triggered either by the IndexProp command or a time-based poll interval. Is a managed node. Serves site traffic.
2	A repeater is not used in this topology.	Resides in Production. Performs full and partial indexing off the production database during off-peak times. Is a managed node. Cannot perform emergency fixes. Does not serve site traffic. Cannot preview index data before replication.	Resides in Production. Replication is pushed. It is triggered either by the IndexProp command or a time-based poll interval. Is a managed node. Serves site traffic.
3	Resides in Production. Performs partial indexing off the production database. Can be a managed or non-managed node. Does not serve site traffic. Performs a delta build of catalog emergency fix changes made by the authoring server in a workspace. Can be used to index production data such as inventory data.	Resides in authoring. Performs full and partial indexing off the authoring database throughout the day. Is a non-managed node. Can perform emergency fixes. Does not serve site traffic. Can preview index data before replication.	Resides in Production. Replication is pulled. It is triggered either by the IndexProp command or a time-based poll interval. Is a managed node. Serves site traffic.