Clustering Oracle Service Registry in an Oracle Application Server 10g R3 Environment

Transcription

1 Clustering Oracle Service Registry in an Oracle Application Server 10g R3 Environment Installing Oracle Service Registry in a Cluster... 1 Additional Steps for Clustering a Publication/Discovery Configuration... 5 Configuring or Disabling the IPFilter on the Discovery Registry... 5 Importing Discovery Certificates on the Publication Nodes... 7 Configuring Registry Configuration Synchronization This document provides instructions on clustering Oracle Service Registry (OSR) instances in an Oracle Application Server (OracleAS) x environment. It is intended to supplement the Oracle Service Registry product documentation (REGISTRY.PDF). Please read that section of the product documentation before configuring an OSR cluster. In the Oracle Application Server context, an OSR cluster is defined as: A cluster of OracleAS instances, each hosting a Standalone Registry instance, with all instances connecting to the same database schema A cluster of OracleAS instances, each hosting a Publication (staging) Registry installation, with all Publication instances connecting to the same database schema A cluster of OracleAS instances, each hosting a Discovery Registry installation, with all Discovery instances connecting to the same database schema Note that if you are configuring a clustered Publication/Discovery Registry installation, you must follow the additional steps outlined in the Additional Steps for Clustering a Publication/Discovery Configuration section below. Installing Oracle Service Registry in a Cluster To install OSR into an OracleAS cluster, you must install each Registry node into an OC4J instance within each OracleAS node. This process is identical to installing OSR in a nonclustered configuration with the following exceptions. You will create the Registry tablespace and schema when you install the first Registry instance, as illustrated below.

2 You will then connect each subsequent Registry instance you install to this database schema.

3 You must supply the existing database username and password as part of this configuration:

4 In the Deployment to Application Server panel of the installer, you will specify the information needed to enable the Registry application to receive client requests. The values must be the same for each Service Registry instance. These values will enable all Registry instances within the cluster to receive requests from the same Oracle HTTP Server instance. Note that you are specifying the following: HTTP Port: The Oracle HTTP Server or loadbalancer listener port SSL Port: The secure listener port that Registry will utilize. This is required if using the Publication/Discovery configuration. Hostname: The Oracle HTTP Server or loadbalancer hostname or virtual IP address not OracleAS instance hostname! Application Server Context: The root context used in the URL to access the application. Ensure this value is identical across instances. Application Server Name: The application name. Ensure this value is identical across instances.

5 If these values are configured correctly, Oracle HTTP Server/loadbalancer will be able to route requests to any OSR instance in the cluster. Additional Steps for Clustering a Publication/Discovery Configuration If you are clustering multiple Publication and/or Discovery Registries, the following additional steps are required. Configuring or Disabling the IPFilter on the Discovery Registry When installing the Discovery Registry, you will be asked for the Discovery Registry Configuration. This is required because an IPFilter that filters incoming requests from the Publication registry is enabled by default on the Discovery registry. Requests from any IP address that the filter is not aware of will be blocked.

6 You must either: Enter the IP address of each HTTP server host or load balancer IP that forwards requests to the Discovery Registry. Note that if your loadbalance utilizes multiple IP addresses, each must be listed here. OR: Disable the IPFilter by setting by setting the value of IPAddress to , which will cause any specified IP addresses to be ignored. The IPFilter configuration is written within the <IPFilter> element in the production.xml file on the Discovery registry server. This file is found within the Discovery registry s OC4J directory structure: <ORACLE >/j2ee/<oc4j_instance>/applications/registry/registry/app/uddi/conf/production.xml

7 Importing Discovery Certificates on the Publication Nodes The Service Registry uses HTTPS communication between the Discovery and Publication Registry nodes. This requires that the credentials from the Discovery Registry s X.509 certificate be copied to the pstore.xml file on each Publication Registry node. This file is located in the following directory on either a Publication or Discovery node: <OracleAS>/j2ee/<oc4j>/applications/<registry>/<registry>/conf Note that the certificate must be exported and saved as a.cer file to be recognized by the Registry. The Registry provides a tool the PstoreTool that facilitates the importing of certificate information into the Publication Registry s pstore.xml file. The tool is deployed by fault to the staging directory created when you install the Registry. You can use a single PstoreTool instance to import certificate information on all of your Publication nodes. The process to import these certificates on each Publication node is as follows: 1. Ensure that the Publication Registry node is running. 2. Open a command prompt and navigate to <staging_dir>/bin. 3. Start PstoreTool in GUI mode by typing: PStoreTool.[bat sh] gui 4. Select Pstore->Open From File...

8 5. Navigate to the pstore.xml file for the Production (staging) Registry node. 6. Right-click in the Aliases window and choose Import alias. 7. Change Type from KEY_ENTRY to TRUSTED_CERTIFICATE_ENTRY.

9 8. Click Load Certificate Chain button and navigate to the certificate (.CER) of Discovery Registry.

10 9. Click Open and then OK. You should now see the selected alias/certificate in the list of aliases.

11 10. Repeat steps 4-9 for each Discovery node if necessary. Typically however a single certificate will exist at either the Oracle HTTP Server or loadbalancer level. 11. Simply close the PStoreTool application when finished. No save is needed; your updates are automatically saved. Configuring Registry Configuration Synchronization In an OSR cluster, changes made to the Registry configuration are actually made to a specific Registry instance within the cluster. These changes are then propagated to the other Registry nodes within the cluster, ensuring that configuration of all nodes are synchronized. This configuration is documented in the Cluster Configuration in the OSR product documentation (registry.pdf). Note that configuring the cluster for synchronization is not explicitly required, but it is strongly recommended. The following Registry configuration data will be synchronized across clustered nodes: Account and security settings

12 Server settings like SMTP properties, default business limits, etc. Web UI settings including web UI endpoints UI page customizations Taxonomy cache updates In this configuration, one OSR node is the manager and remaining nodes are listeners. Any configuration change is sent to the manager which then distributes the change to the other nodes. Note that an HTTPS connection is utilized between the manager and listener nodes. This means that if different hosts are used for Discovery or Publication Registry nodes, the certificate for each node must be imported into the pstore.xml file of every other node as described in the Importing Discovery Certificates on the Publication Nodes section. For example, if you have two Discovery nodes, the certificate for each must be imported into the other s pstore.xml file. As noted in the documentation, the cluster configuration is specified in the configurator.xml file, which is installed in the following directory in within the OC4J directory structure: <oracle>/j2ee/<oc4jinstance>/applications/registry/registry/app/uddi/conf/ The manager node is configured in the <configmanagerurls> element within configurator.xml as illustrated below: <configmanagerurls> <url> <managerserviceurlpath>/[registry]/uddi/configuratormanager</managerserviceurlpath> <managerconfiguratorurlpath>/[registry]/uddi/configurator</managerconfiguratorurlpath> </configmanagerurls> Set <url> to the internal IP address and HTTPS listener port of the OracleAS host containing the manager OSR node. Set [registry] in <managerserviceurlpath> and <managerconfiguratorurlpath> to the context URI defined during installation for the Registry instance. This will generally be either /registry or /registrypub. Next configure the IPFilter, which allows only those incoming configuration change messages from specified IP addresses to be received. That is, if the incoming message comes from a foreign IP address it is ignored and not distributed among the other cluster nodes. <IPFilter name="configuratorfilter"> <subnet IPAddress=" " subnetmask=" "/> </IPFilter> You can either specify all IP addresses of all nodes within cluster or you may use subnetmask if you know that cluster nodes IP addresses will be in the same range. For example, to configure 10.0.*.* :

13 <IPFilter name="configuratorfilter"> <subnet IPAddress=" " subnetmask=" "/> </IPFilter> Finally, you will specify each listener node in a <configuratorlistener> element. The syntax on this URL is as follows: <configuratorlisteners> <configuratorlistener> </configuratorlistener> <configuratorlistener> </configuratorlistener> </configuratorlisteners>