Federating and clustering the WebSphere Commerce search server in the advanced configuration

Once you deploy the WebSphere Commerce search server in the standard configuration, you can federate the node to the deployment manager (DMGR) and create a cluster that contains the WebSphere Commerce and WebSphere Commerce search servers.

Before you begin

Ensure that you complete the following task:

Deploying the WebSphere Commerce search server locally in the standard configuration
Now that the WebSphere Commerce Search server is deployed in the standard configuration, we will need to federate the node to a Deployment Manager so a cluster can be created.

About this task

The following list shows the high-level tasks that are associated with deploying the WebSphere Commerce search server in the advanced configuration in Feature Pack 7 or later:

The WebSphere Commerce and WebSphere Commerce search servers are set up locally on the same machine (standard configuration).
The deployment manager (DMGR) is used to federate the WebSphere Commerce and WebSphere Commerce search servers.
On the new search nodes, custom profiles for WebSphere Commerce search are created and then federated using the DMGR.
The WebSphere Commerce search cluster is created with the new cluster members, where the nodes can be reached for clustering.

Procedure

Federating the search server:

Install the WebSphere Application Server Network Deployment product by using the media that are supplied with WebSphere Commerce. This node now hosts the deployment manager. Although you can install other application servers on the same node as the deployment manager, it is not done unless you have a node with the capacity to host both products.
Create a non-root WebSphere Application Server Deployment Manager profile on the WebSphere Application Server Network Deployment machine. For more information about creating a WebSphere Application Server Deployment Manager profile, see:
- Create a Deployment Manager profile using the WebSphere Application Server Profile Manager
Alternatively, you can use the command line to create the deployment manager profile. For more information, see Using the manageprofiles command.
On the WebSphere Application Server Network Deployment machine, start the deployment manager profile.
- Start the Deployment Manager
Alternatively, you can use the command line to start the deployment manager profile. For more information, see startManager command.
Create the WebSphere Application Server non-root user and group if they do not exist on the WebSphere Commerce search node.
Federate the WebSphere Application Server profile:
1. Log on as the non-root user.
2. Start a Qshell session by typing QSH in the IBM i command prompt.
3. Federate the search server into the deployment manager cell by issuing the addNode command, as shown in the following examples:
  - new_profiledir/bin/addNode.sh deployment_manager_host_name SOAP_port -includeapps [-username uid] [-password pwd] [-localusername localuid] [-localpassword localpwd]
  - new_profiledir/bin/addNode.bat deployment_manager_host_name SOAP_port -includeapps [-username uid] [-password pwd] [-localusername localuid] [-localpassword localpwd]
  Note: The command is shown on multiple lines for display purposes only. Enter the command on one line.
  The variables and parameters in the command are defined as follows:
  
  new_profiledir
  
  This directory is created for the WebSphere Application Server profile that is used by the search server.
  
  deployment_manager_host_name
  
  This name is the fully qualified host name of the deployment manager node.
  
  SOAP_port
  
  This port is the SOAP port on which the deployment manager listens. This port number is defined when you create the deployment manager profile. The default deployment manager port is 8879.
  
  -includeapps
  
  When you federate a WebSphere Commerce search profile that contains a WebSphere Commerce search instance, you must include this parameter. This parameter ensures that the WebSphere Commerce search application (EAR) file is transferred to the new configuration.
  
  username
  
  If security is enabled, specify the user name for authentication. This parameter acts the same as the -user option. The user name that you select must be a preexisting user name.
  
  password
  
  If security is enabled, specify the password for authentication. The password that you choose must be one that is associated with a preexisting user name.
  
  localusername
  
  If security is enabled, specify the user name for authentication for existing application servers on the node that you want to federate.
  
  localpassword
  
  If security is enabled, specify the password for authentication for existing application servers on the node that you want to federate. The password that you choose must be one that is associated with a pre-existing user name.
Ensure that the node has been created successfully:
- Check the command line output to see the result. For example, it might display a result similar to the following message:
```
Node demo_search_node has been successfully federated.
```
- Or, in the deployment manager, go to Server > WebSphere Application Servers and ensure that solrServer exists.
Note: After you federate a WebSphere Application Server profile, the node agent must be managed by the non-root user. For more information, see Changing the process execution properties.
If you enabled security before you federated your WebSphere Commerce search application, you must enable security again.
If the DMGR is enabled with global security, you must update the following values in the WC_installdir\instances\instance_name\search\commerce\properties\searchServer.properties file:
- wasAdminUser=admin_user_id
- wasAdminUserPwd=encrypted_admin_password
Where the encrypted_admin_password value is the encrypted password, using the wcs_encrypt utility without specifying the merchant key. For more information, see Generate encrypted data (wcs_encrypt).
Create the cell-level documents for the search configuration on your WebSphere Commerce search node. Doing so ensures that additional nodes can use the same configuration at the cell-level.
1. Install APAR JR52084 to ensure that the search configuration deploys correctly.
2. Go to the following directory: WC_installdir/bin
3. Run the deployment script:
  - config_ant.sh -buildfile WC_installdir/components/foundation/subcomponents/search/deploy/deploySearch.xml -DdbUserPassword=dbuserpwd -DinstanceName=instance_name [-DsolrHome=solrhome] PrepareWASEnvironment ConfigWebserver GeneratePlugin [-DSolrWASAdminUser=solr_wasadminuser -DSolrWASAdminPassword=solr_wasadminpassword]
  - config_ant.bat -buildfile WC_installdir/components/foundation/subcomponents/search/deploy/deploySearch.xml -DdbUserPassword=dbuserpwd -DinstanceName=instance_name [-DsolrHome=solrhome] PrepareWASEnvironment ConfigWebserver GeneratePlugin [-DSolrWASAdminUser=solr_wasadminuser -DSolrWASAdminPassword=solr_wasadminpassword]
  Where:
  solrhome
  
  The location of the Solr home directory path that contains the index data of Solr. The value must be an absolute path.
  The default value is:
  
  WCDE_installdir/search/solr/home
  
  WC_installdir/instances/instance_name/search/solr/home
  
  WC_instance_root/instances/instance_name/search/solr/home
  
  solr_wasadminuser
  
  The WebSphere Application Server administrator user ID for the Solr cell.
  
  solr_wasadminpassword
  
  The WebSphere Application Server administrator password for the Solr cell.
  When:
  - A previous version of WebSphere Commerce search is enabled from an earlier Feature Pack version (for example, Feature Pack 2), and
  - WebSphere Application Server administrative security is enabled on the search server and Solr cell
Restart the Deployment Manager and the WebSphere Commerce search server.
If you enabled automatic propagation of the web server configuration file (plugin-cfg.xml) before federating, you must configure it again.
Regenerate the Web server plug-in for your Web server:
1. Log on the WebSphere Application Server Network Deployment Administration Console server.
2. Expand Servers > Server Types > Web servers.
3. Select webserver1 and click Generate Plug-in to generate the plugin-cfg.xml file for the web server.
4. Select solrWebserver1 and click Generate Plug-in to generate the plugin-cfg.xml file for the search web server.
Copy the updated plugin-cfg.xml file to your web server.
1. Communicating with web servers
2. Communicating with web servers
Update the path to the plugin-cfg.xml file in the web server configuration file on the web server.
If your web server is configured to use only IPv6, change the custom properties for both the WebSphere Commerce and search server JVMs:
1. In the WebSphere Application Server administrative console for the WebSphere Commerce search server, expand Servers > Server Types. Click WebSphere application servers. In the list of application servers, select your server.
2. On the Configuration tab, expand Java and Process Management and click Process definition > Java Virtual Machine > custom properties.
3. Click New. On the Configuration tab, enter the following name and value:
  Name Value
  java.net.preferIPv6Addresses true
4. Click Apply > Save directly to the master configuration.
Restart your web server.

Name	Value
java.net.preferIPv6Addresses	true

Clustering the federated environment:

After you federate your WebSphere Commerce environment, you can configure clustering. Clustering provides failover protection and workload balancing.

If you plan on replicating WebSphere Commerce search, ensure that you consider the following replication recommendations:

Setup one master search index server to hold the master index, which is then replicated to all the search servers that take search traffic. That is, there typically exists a dedicated index-building machine, which is known as the master, to build the index. There can only be one master; it cannot exist on multiple nodes in clustered environments. The master replicates the index to other search engine machines, which are known as targets. The runtime search performance is not affected during the index-building.
Set up the master search index server and subordinate search index server (separately) on the same operating system. This set up ensures easier file copy operations between servers.
Every deployment manager that has a copy of Solr federated to it, must also have a WebSphere Commerce environment federated to it. Otherwise, fixes and maintenance must be manually applied to each node.

Cluster your WebSphere Commerce search environment. For more information, see WebSphere Commerce search server: Advanced configuration.
Copy the solrhome directory from your master machine to all the search nodes. This copying ensures that the master and subordinate machines all contain the search index data, and that they work together as a cluster.