고급 사용자 정의 > Info*Engine 구현 > Configuring for Load Balancing and Failures
  
Configuring for Load Balancing and Failures
The following topics describe how set up and initialize load balancing and failure processing.
About Load Balancing
To set up load balancing for Info*Engine services as well as provide redundant components in case a component fails, the following processes are available:
You can configure some components for system-wide load balancing and failures by setting up multiple instances of the components and then configuring their LDAP entries so that they have a common service name. These components can be Info*Engine task processors, adapters, or gateways. This configuration is done through the Info*Engine Property Administration utility.
Task and JSP authors can use failure processing techniques within individual tasks or JSPs. These techniques do not require that the components have a common service name. Instead, the techniques allow authors to specify multiple components in the specific task or adapter webject being processed. Authors can also use the CONNECTION_ATTEMPTS and CONNECTION_ATTEMPTS_INTERVAL webject parameters to regulate how often a request is resent and the interval between those requests.
Your site can choose to use one or both of these methods for load balancing and failure processing.
* 
You should not attempt to duplicate the Naming Service instance. Creating duplicate Naming Service LDAP directory entries with a common name can produce unpredictable results.
If you have a Windchill environment that has multiple method servers, do not attempt to configure the Windchill adapter manually. Windchill adapter auto-registration automatically updates the service configuration as necessary to function properly in a multiple method server environment by updating the adapter configuration to use a port range large enough to accommodate all foreground method servers.
System-Wide Load Balancing and Failure Processing
To locate Info*Engine components, the Naming Service starts its search at the LDAP search base specified in its LDAP entry. It locates all component entries under the search base that have the specified name. When there is more than one component with the same name in the search base, Info*Engine randomly chooses the one that receives a request.
If you install an Info*Engine component in only one location and that component fails, an error message is generated and returned to the user or calling application. If you install and configure multiple instances of a component and one of the components fails, the Naming Service sends the request to another instance of the same component.
After you have installed an Info*Engine task processor, adapter, or gateway multiple times, you can set up load balancing and failure processing by configuring the components so that they have a common service name. This configuration is done using the Info*Engine Property Administration utility. After you have established a common service name, task and JSP authors must specify this name in the INSTANCE parameter of the adapter webjects or in the task tag attribute that identifies the task processor to use.
You can configure components so that they have a common service name using the following processes:
Create one LDAP entry for all redundant components. In this entry, all information for the components is the same except that you specify multiple host and port attributes, where each host and port pair match the host and port required for one of the components. If you want to run multiple instances on a single host you can specify a port range in place of a single port number, separating the lower port number from the higher port number with a dash (for example, 1001-1005).
Create an LDAP entry for each component using a unique service name for each component. Edit each LDAP entry and add a common service name as an additional service name. Tell task and JSP authors to use this common service name when accessing the component.
Create an LDAP entry for each component on a unique branch in your directory and use the same service name, but a unique runtime service name, for each component.
* 
If you configure multiple adapter components with the same name and one of the adapters runs in-process, the Naming Service always selects the in-process adapter. Load balancing does not occur in this case. However, if accessing the classes of the in-process adapter produces an error, a connection to an out-of-process adapter is attempted.
The following sections provide examples of setting up these methods of load balancing and failure processing.
Using One LDAP Entry for Multiple Components
Creating one LDAP entry with multiple host and port attributes for redundant components is a quick way to provide for loading balancing and failures. This method requires that all component properties are the same for the components and that the components are accessed through a TCP host and port connection.
This method works well in the following situations:
You have redundant out-of-process adapters that connect to the same data repository.
You have multiple task processors, each with the same properties except for its host and port.
For example, assume that you have set up three JDBC adapters on three different hosts that are all configured identically to access the same database. If this is true, the properties for the adapters can be the same, except for the host and port used to access the adapters. To set up load balancing across all three adapters, you could set the following attributes on one adapter LDAP entry:
Service Name
Host
Port
com.myCompany.JDBC
oradb1.co.com
10003
oradb2.co.com
10004
oradb3.co.com
10005
* 
If you have a Windchill environment that has multiple method servers, do not attempt to use one LDAP entry for multiple Windchill adapters. Windchill adapter auto-registration automatically creates and removes service definitions as necessary. Separate adapter definitions are necessary to maintain proper session affinity during distributed transaction processing.
Editing LDAP Entries to Add a Common Service Name
Creating unique LDAP entries for each component and then adding a common service name as an additional service name allows the entries to reside in the same branch in your LDAP directory. This provides flexibility in setting the properties for redundant components. All of the entries can reside in the same branch because each entry has a unique service name which, by default, makes the distinguished name for the service unique. The common service name that is added after the creation of the LDAP entry is the name used when the Naming Service searches for services; it does not become part of the distinguished name for the service.
Using this method can work well when you have multiple instances of the Info*Engine task processor or an adapter that may have different properties but still provides the same function in your environment.
For example, assume that you have three task processors, each residing on a different host, and because the hosts do not have the same capacity, you do not want the Max Thread Count field on each processor LDAP entry form set to the same number. You can then modify the three LDAP entries for the task processors.
Assume that these entries were created when you installed the Info*Engine servers on their respective hosts and that you have set up your environment to run the Naming Service from one of the hosts. To specify the maximum number of requests allowed at one time, and to provide load balancing and failure processing between these task processors, edit the service properties through the Info*Engine Property Administration utility. On each server form, enter the number of requests to allow in the Max Thread Count field. For example, the following table lists the unique service names of three task processors and a maximum thread count for each:
Service Name
Host
Port
Max Thread Count
com.myCompany.myLocation.aHost.server.taskProcessor
aHost
10003
60
com.myCompany.myLocation.bHost.server.taskProcessor
bHost
10004
200
com.myCompany.myLocation.cHost.server.taskProcessor
cHost
10005
80
The service names for these entries use the default distinguished names and runtime service names to produce three unique services.
On each form, also add a common task processor service name by typing the common name in the field under the existing service name and clicking Add. For example, you could add the service name “com.myCompany.myLocation.infoengineServer.taskProcessor.” Then when the Naming Service receives requests for a task processor that has this common name, it randomly chooses one of the three task processors with the common name. If the one selected does not respond, another is chosen.
Using Unique Branches and the Same Service Name
Having multiple LDAP entries with the same service name in unique branches of the LDAP directory provides you with the most flexibility in setting the properties for the components. Using this method assumes that you have set up unique branches in your LDAP server under which the entries can reside (as defined in the distinguished name for each service). The Info*Engine Property Administration utility does not create branches; they must exist before you open Property Administration to add the LDAP entries. Required branches can be created through the Create Repository option in the Task Delegate Administration utility.
This method can work well when you have a complex branching system set up in your LDAP directory and when you have multiple Info*Engine environments. You can restrict access to certain components to certain environments, but allow for load balancing in other environments.
For example, assume that there are three data repositories with unique properties for each repository and that the same JDBC adapter is installed three times, one for each repository. To set up load balancing across all three adapters, you could set the following attributes on the adapter LDAP entries:
Service Name
Host
Port
DN Subtree Values
com.myCompany.JDBC
oradb1.co.com
10003
dc=aHost,dc=myCompany,dc=com
com.myCompany.JDBC
oradb2.co.com
10004
dc=bHost,dc=myCompany,dc=com
com.myCompany.JDBC
oradb3.co.com
10005
dc=cHost,dc=myCompany,dc=com
Also, assume that each entry has a unique DBUSER attribute that identifies the username for accessing the database. Therefore, in each LDAP entry the service name value is the same (com.myCompany.JDBC) and the host, port, database user, and distinguished name subtree values are unique. In this example, the entries each have unique ptcRuntimeServiceName attributes so that each component has its unique set of properties.
When the Naming Service receives requests for an instance of “com.myCompany.JDBC” and the Naming Service search base is set at the LDAP entry of “dc=myCompany,dc=com,” the Naming Service balances the load across all three JDBC adapters. To do load balancing, Info*Engine randomly selects which of the three adapters receives each query and each adapter connects to a different database.
Service Failure Processing in Specific Tasks and Webjects
Task and JSP authors can use the following failure processing techniques within individual tasks or JSPs. These techniques do not require that the components have a common service name.
Service Failures in Tasks
Using multiple processor attributes on a task tag allows an author to specify multiple task processors that can execute the specified task. If the first processor listed is not available, Info*Engine attempts to connect to the next one in the list. This process continues until a connection is made or until all processors have been tried.
* 
When searching for a processor named in a task tag processor attribute, the Naming Service identifies multiple processors with the given name and then randomly selects which processor to use. The Naming Service only goes on to other processors in the list after all processors with the common name have been tried. For more information, see the section "System-Wide Load Balancing and Failure Processing".
For additional information about the using the task tag, see Info*Engine Tags.
Service Failures in Adapter Webjects
Using multiple INSTANCE parameter values on an adapter webject allows an author to specify multiple adapters that can execute the specified webject. If the first adapter listed is not available, Info*Engine attempts to connect to the next one in the list. This process continues until a connection is made or until all adapters have been tried.
* 
When searching for an adapter named in a webject INSTANCE parameter, the Naming Service identifies multiple adapters with the given name and then randomly selects which adapter to use. The Naming Service only goes on to other adapters in the list after all adapters with the common name have been tried. For more information, see the section “System-Wide Load Balancing and Failure Processing”.
Info*Engine also provides the following parameters, which can be useful in structuring failure processing:
CONNECTION_ATTEMPTS
Defines the maximum number of times to attempt establishing a connection to an adapter before returning an error. If multiple INSTANCE parameter values are specified, the value of CONNECTION_ATTEMPTS defines the maximum number of times to iterate through the list of adapter instances.
CONNECTION_ATTEMPT_INTERVAL
Defines the amount of time, in seconds, to delay between connection attempts. If multiple INSTANCE parameter values are specified, the value of CONNECTION_ATTEMPT_INTERVAL defines the number of seconds to wait between the attempts to iterate through the entire list of adapter instances.
For additional information about the using these parameters and the INSTANCE parameter on adapter webjects, see the adapter guides for the adapters you are using.