Automatically sharing configurations among replicas

Overview

We can configure one collective controller server.xml include file in a replica set and automatically update the configuration of other replicas in the set. Automatic sharing of configurations means that we do not need to manually update the configurations of other replicas. Automatic sharing of configurations is especially useful for collectives that use auto scaling.

For an example of creating a replica set consisting of three collective controllers on the same host see Example: Create and activate a replica set

We can drop the include file for a controller configuration into configDropins/defaults of that controller to automatically update the configuration of replicas. Alternatively, we can use ControllerConfigMBean operations to list, add, or remove the shared configuration files of a collective controller.

Share configuration among replicas

  1. Create a replica set.

  2. Create a configDropins directory for the controller with the configuration we want to share among replicas.

    For information about precedence among files in configDropins subdirectories, see Use the configuration dropins folder to specify server configuration. Controller configurations dropped into a configDropins/overrides directory are not shared among replicas. To share configurations among replicas, use the configDropins/defaults directory.

  3. Share the controller configuration with other replicas in the replica set.

    Note: When sharing controller configuration with other replicas, the <collectiveHostAuthInfo element must be configured with specific SSH key paths or a SAF keyring configuration.

    • Drop the configuration of the replica set controller into its configDropins/defaults directory.

      For example, copy the server.xml include file of the controller to its configDropins/defaults directory.

    • Use ControllerConfigMBean operations to list, add, or remove the shared configuration files of a collective controller.

      Configuration files are stored in...

        $WLP_USER_DIR/servers/server_name/configDropins/defaults

      ...of the controllers and are shared with the configDropins/defaults directory of the replicas.

      Use Jython scripts or a Java client such a JConsole to perform the following collective controller ControllerConfigMBean operations:

        listSharedConfig

        The listSharedConfig operation lists the files in the shared configuration directory of the replica.

        addSharedConfig

        The addSharedConfig operation adds a configuration to a file and stores the file in the configDropins/defaults directory of each replica. We must specify two parameters for the operation:

          fileName

          The file name of the controller configuration to share. If we specify a file name that exists in the shared configuration directory, the existing file is overwritten. (String)

          config

          The content of a valid server.xml include file. (String)For example:

            <?xml version="1.0" encoding="UTF-8" ?>
            <server>
              <logging traceSpecification="com.ibm.ws.collective.repository.internal.SharedConfigManager=all"/>
            </server>

        removeSharedConfig

        The removeSharedConfig operation removes a file from the configDropins/defaults directory of each replica. We must specify a parameter for the operation:

          fileName

          The file name of the controller configuration to delete from the shared configuration directory of each replica. (String)

    • When sharing controller configuration with other replicas, the <collectiveHostAuthInfo> element must be configured with specific SSH key paths or a SAF keyring configuration.

    The controller configuration automatically synchronizes with the configuration dropins directories of every other replica in the replica set. When we add a replica to a controller that automatically shares its configuration, the content of the configDropins/defaults directory of the controller is replicated to the new replica. Any changes that you make to scaling policy definitions for one controller automatically synchronize with configurations in the configuration dropins directories of the other replicas.

    If the controller configuration does not automatically synchronize with the configuration of other replicas, check the controller and replica logs. Also, if we used the configDropins/defaults directory to share the controller configuration, ensure that configuration monitoring is not turned off. By default, configuration monitoring is enabled. If configuration monitoring is unavailable, we can use the FileNotificationMBean to inform the controller of configuration changes, and then the changes are shared with the replicas. Configurations stored by ControllerConfigMBean operations are automatically shared among replicas whether configuration monitoring is enabled or not.

    See Control dynamic updates.


Example: Use JConsole to share the controller configuration among replicas

This example describes how we might use JConsole to share the server.xml include file in the controller configDropins/defaults directory with all replicas:

  1. Connect JConsole to the collective controller process.

    1. Ensure the collective controller is running.

        wlp/bin/server status collective_controller_name

      Replicas do not need to be running. Replicas that are not running synchronize the shared configuration when they start.

    2. Start JConsole if it is not running.

        /java_installation/bin/jconsole.sh

    3. Select the process for the collective controller.

  2. Run the ControllerConfigMBean addSharedConfig operation in JConsole to add the controller server.xml include file to the configDropins/defaults directory of each replica.

    1. Go to the JConsole MBeans tab

    2. Select the ControllerConfigMBean addSharedConfig operation.

    3. For fileName, specify the path of the server.xml include file; for example:

        $WLP_USER_DIR/servers/collective_controller_name/trace.xml

    4. For config, specify the configuration to add; for example:

        <?xml version="1.0" encoding="UTF-8" ?>
        <server>
          <logging traceSpecification="com.ibm.ws.collective.repository.internal.SharedConfigManager=all"/>
        </server>

    5. Click addSharedConfig to run the operation.

  3. Confirm that the operation successfully shared the controller configuration among the replicas.