+

Search Tips   |   Advanced Search

Generate the plug-in configuration in a high availability environment

  1. Establish a high availability environment.

  2. Using the the high availability plugin-cfg generation service described below does not automatically disable the ODR plugin-cfg generation, if enabled. The two services are independent and it is redundant to enable both services. When enabling the high availability plugin-cfg generation service, disable any previously configured ODR plugin-cfg generation.

  3. If we enable Intelligent Management for a web server, do not use the option to dynamically generate plugin-cfg.xml for that web server.

    Dynamically generating plugin-cfg.xml overwrites the Intelligent Management settings in plugin-cfg.xml.

  4. Define a set of custom properties at the cell level for each plugin-cfg.xml file to generate.

    The custom properties are formatted as...

      ODCPluginCfg<property>_<definitionID>=value

    ...where <property> is one of the following elements...

    The <definitionID> variable is the name of the configuration chosen. As a result, properties ending in the same <definitionID> variable define a single generation definition within the high availability plug-in configuration generation service.

    The ODCPluginCfgUpdateScript_<definitionID> value can be set with the same options as the values in the Plugin config change script text box.


Generate HAPluginCfgGeneration definitions on demand

  1. Disable automatic generation.

    Set the cell custom property ODCPluginCfgDisabled_<definitionID> to true.

  2. To generate a new plug-in, run this command:

      <WAS_HOME>/bin/wsadmin.sh -lang jython -f <WAS_HOME>/bin/manageODC.py generateHAPluginCfgs <generationDefinitionIDs> nodeName serverName

    where:

      generationDefinitionIDs

      List of HAPluginCfgGeneration IDs separated by commas of the form ODCPluginCfg_<definitionID>.

      nodeName

      Name of the node that performs the generation.

      serverName

      Process name that performs the generation. Any Intelligent Management augmented process can generate the HAPluginCfgs configuration on demand, except for XDAGENT processes. For example:

        <WAS_HOME>/bin/wsadmin.sh -lang jython -f <WAS_HOME>/bin/manageODC.py generateHAPluginCfgs ODCPluginCfg_1,ODCPluginCfg_2 dmgrNodeName dmgr


Limit how often the HAPluginCfgGeneration definitions are regenerated

Set the cell custom property ODCPluginCfgMinGenerationDelay with a value that represents the time in minutes between possible generations. For example:

The configured HAPluginCfgGeneration definitions are regenerated every 10 minutes at the most. If the generator receives notification to rebuild the pluginCfgs, it delays the generation of pluginCfgs written within the last 10 minutes.


Limit how often an ODR generated plugin-cfg.xml file is regenerated

Set the JVM property com.ibm.ws.odr.plugincfg.minGenerationDelay to a value that represents the time in minutes between possible generations and then cycle the ODR.


Include stopped ODR processes in a generated plugin-cfg.xml file based on the current runtime weight value

By default, the configured static runtime weight value (0) is used. To include stopped ODR processes in a generated plugin-cfg.xml file, configure the following settings:


Configure the high availability plugin-cfg generation service

  1. In the administrative console, click...

      System administration > Cell > Custom properties > New

  2. Define the following custom properties:

      ODCPluginCfgOdrList_<definitionID>=cell1:node1:odr1,cell2:node2:*,[cell1:node3:odr3],[cell1:node4:odr4]

      ODRs to include in plugin-cfg.xml. Use the asterisk (*) symbol as a valid wildcard for each path segment.odr1 and odr2 are marked as primary servers. odr3 and odr4 are marked as backup servers.

      ODCPluginCfgOutputPath_<definitionID>=/path/file_name.txt

      Location in which plugin-cfg.xml is placed after the file is generated. Because we can generate the plug-in configuration on any node in the cell, ensure the output directory exists on each node.

      ODCPluginCfgUpdateScript_<definitionID>=/path/script <parameter1> <parameter2>

      Absolute path to your script and the arguments to be passed to your defined script. The defined script will be invoked each time a plugin-cfg.xml is generated.

      ODCPluginCfgOdrClusterList_<definitionID>=cell1:cluster1,cell1:cluster2,cell1:*,[cell1:cluster3],[cell1:cluster4]

      Cluster of ODRs to include in plugin-cfg.xml. Use the asterisk (*) symbol as a valid wildcard for each path segment.cluster1 and cluster2 are marked as primary servers. cluster3 and cluster4 are marked as backup servers.

      ODCPluginCfgDisabled_<definitionID>

      Disable the generation of a particular configuration without disabling all the properties for that configuration. The default is false.

      ODCPluginCfgOdrSessionIdCookie_<definitionID>

      Define the name of the cookie used to maintain IBM HTTP server/ODR affinity when using ODR cell affinity.

      ODCPluginCfgIHSConfigProperties_<definitionID>

      This property is used instead of configuring JVM properties (as is done during non-HA plugin-cfg.xml generation) to set IBM HTTP server specific configuration properties. The value of this property is a comma separated list of ATTRIBUTE_NAME=value pairs where ATTRIBUTE_NAME is the name of an attribute represented in the plugin-cfg.xml.

      For example, if a configuration name of 1 is being used, a cell property named ODCPluginCfgIHSConfigProperties_1 with a value of TrustedProxyEnable=true,LogLevel=INFO,CloneSeparatorChange=true,ServerIOTimeout=60 would be created to set the TrustedProxyEnable, LogeLevel, CloneSeparatorChange, and ServerIOTimeout attributes contained in the generated plugin-cfg.xml.

      ODCPluginCfgTrustedProxyList_<definitionID>=trustedproxy1,trustedproxy2

      Trusted proxies to include in plugin-cfg.xml.

    See Controlling the generation of plugin-cfg.xml for the list of valid property names and values.

Set the following cell custom properties to generate the plug-in configuration for a collection of ODRs that are not in an ODR cluster. Note that all properties end with _1, which ties them together into a single configuration.

Property name Property value Description
ODCPluginCfgOdrList_1

 myCell:*:*

 Generates a plug-in configuration that will route to all ODRs in the myCell cell.

ODCPluginCfgOutputPath_1

 /tmp/plugin-cfg1.xml

 Writes the generated plug-in configuration to the /tmp/plugin-cfg1.xml file.

ODCPluginCfgUpdateScript_1

 /root/bin/pluginCfgUpdate1

 The path to the script that will be invoked each time the /tmp/plugin-cfg1.xml file is updated.

Set the following custom properties to generate the plug-in configuration for a cluster of ODRs named myCell/myOdrCluster. Note that all properties end with _2, which ties them together into a single configuration.

Property name Property value Description
ODCPluginCfgOdrClusterList_2

 myCell:myOdrCluster

 Generates a plug-in configuration that will route to all ODRs of the myOdrCluster cluster in the myCell cell.

ODCPluginCfgOutputPath_2

 /tmp/plugin-cfg2.xml

 Writes the generated plug-in configuration to the /tmp/plugin-cfg2.xml file.

ODCPluginCfgUpdateScript_2

 /root/bin/pluginCfgUpdate2

 The path to the script that is ran each time the /tmp/plugin-cfg2.xml file is updated.

ODCPluginCfgOdrIncludeStopped_2

 true or false

 Includes or excludes stopped ODRs.


What to do next

Because the generation of plugin-cfg.xml can occur on any node in the cell, we can determine the specific location in which the generation service is running:

In the administrative console, click...

Verify that HAPluginCfgGenerator is displayed in the table.


Related:

  • Overview of request flow prioritization
  • Segregating HTTP traffic by ODR clusters
  • Configure an ODR to dynamically update the web server plug-in configuration
  • Intelligent Management: controlling the generation of plugin-cfg.xml
  • Set up a high availability environment