WSO2 Carbon Registry Kernel contains three main partitions of the Registry space. Those are namely Local Data Repository, Configuration Registry and Governance Registry. These three partitions are available on all the products based on WSO2 Carbon Platform, which allows to share resources and configuration replication.
|
Date: Tue, 20th Apr, 2010
Level:
Intermediate
Reads: 8241
Discuss this article on Stack Overflow
|
|
|
|
Contents
Applies To
Introduction
WSO2 Carbon is the base platform for all WSO2 Java products. Built on OSGi, Carbon encapsulates major SOA functionality along with a set of core services available to all WSO2 Java products in common. The Registry kernel of Carbon provides the basic registry and repository functionality. Products based on Carbon uses the services provided by the Registry kernel to establish its own registry space, which is utilized for storing data and persisting configuration.
The Registry space provided to each product contains three major partitions.
- The Local Data Repository
- The Configuration Registry
- The Governance Registry
The local data repository contains system configuration as well as runtime data that is local to a single instance of a product. For example,
the local data repository i
s used to store mount configurations that are local to each instance. This partition of the registry space is not intended to be shared among multiple servers. The
configuration registry, which is the most widely used partition of the registry space, c
ontains product specific configuration. These configuration can be shared across multiple instances of the same product (a cluster of ESB nodes for example). The third and final partition of the registry space is the g
overnance registry, which contains data and configuration shared across the platform. The
WSO2 Governance Registry makes use of this partition of the registry space to store services and related metadata such as WSDLs, schemas, policies and endpoints. The governance registry partition has been designed in a way that it can be made use of by multiple instances of various Carbon based products.
Deployment Strategies
Two of the three partitions mentioned above can be shared across multiple product instances. Therefore, we can identify four main deployment strategies.
Strategy A
The entire registry space is local to the single server instance. The registry space is not shared in this deployment strategy. This is the recommended deployment strategy for a single instance
(stand-alone deployment) of a product. You also could use this model, if you have two or more instances of a product and do not require sharing data or configuration among them.
Strategy B
The configuration and governance registry is shared among instances of a group/cluster. For example, a set of
WSO2 Enterprise Service Bus instances that have been configured to operate in a clustered environment can have a single configuration and governance registry which is shared across each node of the cluster. A separate instance of the
WSO2 Governance Registry is used to provide the space used in common.
Strategy C
Th
e configuration registry remains local to each node while the governance registry is shared among two or more nodes. This strategy is
ideal for a deployment involving instances of multiple products. Such as the
WSO2 Web Services Application Server,
WSO2 Enterprise Service Bus and the
WSO2 Governance Registry.
The governance registry space of each product instance will be a shared space provided by the WSO2 Governance Registry instance.
Strategy D
Both the configuration registry and the governance registry will be shared among nodes in this model. However, the sharing happens at two levels. The configuration registries of multiple instances of a single product group/cluster will be shared among the member nodes. The governance registries of all instances (belonging to one or more products) will be shared among each other. This strategy is ideal when there are clusters of multiple products involved. An example is a deployment involving a cluster of
WSO2 Web Services Application Server nodes and a cluster of
WSO2 Enterprise Service Bus nodes.
In here, three instances of
WSO2 Governance Registry can be used to provide the spaces shared at various levels. The first instance provides the space for the shared configuration registry for the
WSO2 Web Services Application Server cluster. The second provides the space for the shared configuration registry for the
WSO2 Enterprise Service Bus cluster. And, the third provides the space for the governance registry shared among the members of both clusters.
This strategy can also be thought of as a combination of the strategy B and strategy C.
Configuration Options
In order to separate the registry space into partitions that can be shared across multiple nodes, we first need to configure the Registry Kernel of each instance. This can be done by editing the corresponding
registry.xml file found in the
CARBON_HOME/repository/conf directory. The
WSO2 Carbon 3.0.0 release includes two types of configuration models that can be used.
- JDBC-based configuration model
- Atom-based configuration model
The difference between the two models is that the JDBC-based configuration model uses database calls to communicate with remote instances providing the shared space for a given partition, while to Atom-based configuration model uses Atom Publishing Protocol (AtomPub) over HTTP for the remote calls.
The JDBC-based configuration model
This model involves three main types of configuration elements.
- The database configuration
- The remote instance configuration
- The mount configuration
The database configuration should include JDBC connection details (or the data source information) required to connect to each database (one for the configuration registry, and another for the governance registry), as applicable. The remote instance configuration defines the database configuration to use, whether instance is used in READ-ONLY mode, and the root of the registry that is being mounted. Finally, the mount configuration defines the mount path on the local instance along with the target path on the remote instance. The configurations for the four main strategies described above are as follows.
Please note that we have used the MySQL DBMS as an example. Details on how to configure other supported DBMS are found in
here. Also, it is important to note that we have assumed that you will use the existing configuration for the Registry Kernel as it is, and add the following configuration in addition to what's already on the registry.xml file.
Strategy A
This strategy requires no additional configuration.
Strategy B
In here, we will be considering a cluster
WSO2 Enterprise Service Bus nodes sharing the configuration and governance registry space provided by the
WSO2 Governance Registry. To start with, you will have to create a collection named
/_system/nodes
on the
WSO2 Governance Registry instance. Also, let's assume that the
WSO2 Governance Registry instance has a database configuration as follows:
<currentDBConfig>wso2registry</currentDBConfig>
<dbConfig name="wso2registry">
<url>jdbc:mysql://10.20.30.40:3306/registryDB</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
Then, the corresponding configuration that is required to be added to the registry.xml file of the
WSO2 Enterprise Service Bus master node will be:
<dbConfig name="sharedRegistry">
<url>jdbc:mysql://10.20.30.40:3306/registryDB</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<remoteInstance url="https://10.20.30.40:9443/registry">
<id>sharedRegistryInstance</id>
<dbConfig>sharedRegistry</dbConfig>
<readOnly>false</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>sharedRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>sharedRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
and, the corresponding configuration that is required to be added to the registry.xml files of each
WSO2 Enterprise Service Bus slave node will be:
<dbConfig name="sharedRegistry">
<url>jdbc:mysql://10.20.30.40:3306/registryDB</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<remoteInstance url="https://10.20.30.40:9443/registry">
<id>sharedRegistryInstance</id>
<dbConfig>sharedRegistry</dbConfig>
<readOnly>true</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>sharedRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>sharedRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Strategy C
In here, we will be considering a single
WSO2 Enterprise Service Bus node and a single
WSO2 Web Services Application Server node sharing the governance registry space provided by the
WSO2 Governance Registry. Let's assume that the
WSO2 Governance Registry instance has a database configuration as follows:
<currentDBConfig>wso2registry</currentDBConfig>
<dbConfig name="wso2registry">
<url>jdbc:mysql://10.20.30.40:3306/registryDB</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
Then, the corresponding configuration that is required to be added to the registry.xml files of the
WSO2 Enterprise Service Bus node and the
WSO2 Web Services Application Server node will be:
<dbConfig name="governanceRegistry">
<url>jdbc:mysql://10.20.30.40:3306/registryDB</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<remoteInstance url="https://10.20.30.40:9443/registry">
<id>governanceRegistryInstance</id>
<dbConfig>governanceRegistry</dbConfig>
<readOnly>false</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Strategy D
In here, let's assume that we have a cluster of
WSO2 Enterprise Service Bus nodes and a cluster of
WSO2 Web Services Application Server nodes sharing a governance registry space provided by a
WSO2 Governance Registry node named
G-Reg 1. Let's also assume that the cluster of
WSO2 Enterprise Service Bus share a configuration registry space provided by a
WSO2 Governance Registry node named
G-Reg 2 and the cluster of
WSO2 Web Services Application Server share a configuration registry space provided by a
WSO2 Governance Registry node named
G-Reg 3.
To start with, you will have to create a collection named
/_system/nodes
on the instances
G-Reg 2 and
G-Reg 3. Also, let's assume that the
G-Reg 1 instance has a database configuration as follows:
<currentDBConfig>wso2registry</currentDBConfig>
<dbConfig name="wso2registry">
<url>jdbc:mysql://10.20.30.41:3306/registryDB1</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
and, the
G-Reg 2 instance has a database configuration as follows:
<currentDBConfig>wso2registry</currentDBConfig>
<dbConfig name="wso2registry">
<url>jdbc:mysql://10.20.30.42:3306/registryDB2</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
and, the
G-Reg 3 instance has a database configuration as follows:
<currentDBConfig>wso2registry</currentDBConfig>
<dbConfig name="wso2registry">
<url>jdbc:mysql://10.20.30.43:3306/registryDB3</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
Then, the corresponding configuration that is required to be added to the registry.xml file of the
WSO2 Enterprise Service Bus master node will be:
<dbConfig name="configRegistry">
<url>jdbc:mysql://10.20.30.42:3306/registryDB2</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<dbConfig name="governanceRegistry">
<url>jdbc:mysql://10.20.30.41:3306/registryDB1</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<remoteInstance url="https://10.20.30.42:9443/registry">
<id>configRegistryInstance</id>
<dbConfig>configRegistry</dbConfig>
<readOnly>false</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<dbConfig>governanceRegistry</dbConfig>
<readOnly>false</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>configRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
and, the corresponding configuration that is required to be added to the registry.xml files of each
WSO2 Enterprise Service Bus slave node will be:
<dbConfig name="configRegistry">
<url>jdbc:mysql://10.20.30.42:3306/registryDB2</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<dbConfig name="governanceRegistry">
<url>jdbc:mysql://10.20.30.41:3306/registryDB1</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<remoteInstance url="https://10.20.30.42:9443/registry">
<id>configRegistryInstance</id>
<dbConfig>configRegistry</dbConfig>
<readOnly>true</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<dbConfig>governanceRegistry</dbConfig>
<readOnly>true</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>configRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Also, the corresponding configuration that is required to be added to the registry.xml file of the
WSO2 Web Services Application Server master node will be:
<dbConfig name="configRegistry">
<url>jdbc:mysql://10.20.30.43:3306/registryDB3</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<dbConfig name="governanceRegistry">
<url>jdbc:mysql://10.20.30.41:3306/registryDB1</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<remoteInstance url="https://10.20.30.43:9443/registry">
<id>configRegistryInstance</id>
<dbConfig>configRegistry</dbConfig>
<readOnly>false</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<dbConfig>governanceRegistry</dbConfig>
<readOnly>false</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>configRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
and, the corresponding configuration that is required to be added to the registry.xml files of each
WSO2 Web Services Application Server slave node will be:
<dbConfig name="configRegistry">
<url>jdbc:mysql://10.20.30.43:3306/registryDB3</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<dbConfig name="governanceRegistry">
<url>jdbc:mysql://10.20.30.41:3306/registryDB1</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<remoteInstance url="https://10.20.30.43:9443/registry">
<id>configRegistryInstance</id>
<dbConfig>configRegistry</dbConfig>
<readOnly>true</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<dbConfig>governanceRegistry</dbConfig>
<readOnly>true</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>configRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Optionally, you can add the following configuration to the registry.xml files of
G-Reg 2 and
G-Reg 3, so that the governance registry found at each node in the deployment would point to the same location.
<dbConfig name="governanceRegistry">
<url>jdbc:mysql://10.20.30.41:3306/registryDB1</url>
<userName>regadmin</userName>
<password>regadmin</password>
<driverName>com.mysql.jdbc.Driver</driverName>
<maxActive>80</maxActive>
<maxWait>6000</maxWait>
<minIdle>5</minIdle>
</dbConfig>
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<dbConfig>governanceRegistry</dbConfig>
<readOnly>false</readOnly>
<registryRoot>/</registryRoot>
</remoteInstance>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Another variation to the original strategy is to use a single
WSO2 Governance Registry instead of having three distinct nodes. In order to do this, we need to create two collections named
/_system/nodes1
and
/_system/nodes2
. In this scenario, the target path of the governance registry mount of the nodes of the
WSO2 Enterprise Service Bus cluster would be
/_system/nodes1
and the target path of the governance registry mount of the nodes of the
WSO2 Web Services Application Server cluster would be
/_system/nodes2
. The JDBC URL of all configurations mentioned above would then be something similar to
jdbc:mysql://10.20.30.40:3306/registryDB
and the remote instance URL of all configurations mentioned above would then be something similar to
https://10.20.30.40:9443/registry
.
The Atom-based configuration model
This model involves two main types of configuration elements.
- The remote instance configuration
- The mount configuration
Unlike the JDBC-based configuration model, the Atom-based configuration model only requires two configuration elements. The remote instance configuration is a bit different and defines the URL of the remote registry along with valid credentials that can connect to it. The mount configuration is the same as in the JDBC-based configuration model which defines the mount path on the local instance along with the target path on the remote instance. The configurations for the four main strategies described above are as follows.
Once again (as in the JDBC-based configuration model), it is important to note that we have assumed that you will use the existing configuration for the Registry Kernel as it is, and add the following configuration in addition to what's already on the registry.xml file.
Strategy A
This strategy requires no additional configuration.
Strategy B
In here, we will be considering a cluster
WSO2 Enterprise Service Bus nodes sharing the configuration and governance registry space provided by the
WSO2 Governance Registry. To start with, you will have to create a collection named
/_system/nodes
on the
WSO2 Governance Registry instance. Also, let's assume that the URL of
WSO2 Governance Registry instance is
https://10.20.30.40:9443/registry
. Then, the corresponding configuration that is required to be added to the registry.xml file of the
WSO2 Enterprise Service Bus master node will be:
<remoteInstance url="https://10.20.30.40:9443/registry">
<id>sharedRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>sharedRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>sharedRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
and, the corresponding configuration that is required to be added to the registry.xml files of each
WSO2 Enterprise Service Bus slave node will be:
<remoteInstance url="https://10.20.30.40:9443/registry">
<id>sharedRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>sharedRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>sharedRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Strategy C
In here, we will be considering a single
WSO2 Enterprise Service Bus node and a single
WSO2 Web Services Application Server node sharing the governance registry space provided by the
WSO2 Governance Registry. Let's assume that the URL of
WSO2 Governance Registry instance is
https://10.20.30.40:9443/registry
. Then, the corresponding configuration that is required to be added to the registry.xml files of the
WSO2 Enterprise Service Bus node and the
WSO2 Web Services Application Server node will be:
<remoteInstance url="https://10.20.30.40:9443/registry">
<id>governanceRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Strategy D
In here, let's assume that we have a cluster of
WSO2 Enterprise Service Bus nodes and a cluster of
WSO2 Web Services Application Server nodes sharing a governance registry space provided by a
WSO2 Governance Registry node named
G-Reg 1. Let's also assume that the cluster of
WSO2 Enterprise Service Bus share a configuration registry space provided by a
WSO2 Governance Registry node named
G-Reg 2 and the cluster of
WSO2 Web Services Application Server share a configuration registry space provided by a
WSO2 Governance Registry node named
G-Reg 3.
To start with, you will have to create a collection named
/_system/nodes
on the instances
G-Reg 2 and
G-Reg 3. Let's assume that the URLs of the instances
G-Reg 1,
G-Reg 2 and
G-Reg 3 are
https://10.20.30.41:9443/registry
,
https://10.20.30.42:9443/registry
, and
https://10.20.30.43:9443/registry
.
Then, the corresponding configuration that is required to be added to the registry.xml file of the
WSO2 Enterprise Service Bus master node will be:
<remoteInstance url="https://10.20.30.42:9443/registry">
<id>configRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>configRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
and, the corresponding configuration that is required to be added to the registry.xml files of each
WSO2 Enterprise Service Bus slave node will be:
<remoteInstance url="https://10.20.30.42:9443/registry">
<id>configRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>configRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Also, the corresponding configuration that is required to be added to the registry.xml file of the
WSO2 Web Services Application Server master node will be:
<remoteInstance url="https://10.20.30.43:9443/registry">
<id>configRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>configRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
and, the corresponding configuration that is required to be added to the registry.xml files of each
WSO2 Web Services Application Server slave node will be:
<remoteInstance url="https://10.20.30.43:9443/registry">
<id>configRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<mount path="/_system/config" overwrite="true">
<instanceId>configRegistryInstance</instanceId>
<targetPath>/_system/nodes</targetPath>
</mount>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Optionally, you can add the following configuration to the registry.xml files of
G-Reg 2 and
G-Reg 3, so that the governance registry found at each node in the deployment would point to the same location.
<remoteInstance url="https://10.20.30.41:9443/registry">
<id>governanceRegistryInstance</id>
<username>username</username>
<password>password</password>
</remoteInstance>
<mount path="/_system/governance" overwrite="true">
<instanceId>governanceRegistryInstance</instanceId>
<targetPath>/_system/governance</targetPath>
</mount>
Another variation to the original strategy is to use a single
WSO2 Governance Registry instead of having three distinct nodes. In order to do this, we need to create two collections named
/_system/nodes1
and
/_system/nodes2
. In this scenario, the target path of the governance registry mount of the nodes of the
WSO2 Enterprise Service Bus cluster would be
/_system/nodes1
and the target path of the governance registry mount of the nodes of the
WSO2 Web Services Application Server cluster would be
/_system/nodes2
. The remote instance URL of all configurations mentioned above would then be something similar to
https://10.20.30.40:9443/registry
.
Summary
Having read through this tutorial, we have understood the three main partitions of the Registry space of the WSO2 Carbon Registry Kernel. All the products based on the WSO2 Carbon Framework contains these three partitions allowing resource sharing and configuration replication. We have understood the various strategies that we can use to share these registry spaces among multiple product instances.
Having understood the various strategies to share the registry space, we then went through some sample configurations (based around the MySQL database for the JDBC-based configuration model).
Author :
Senaka Fernando, Software Engineer, WSO2 Inc., senaka at wso2 dot com
Hi Senaka, Very informative
Re: Hi Senaka, Very informative
A Great Article
Error while following strategy B
Re: Error while following strategy B
Hi Senaka Send you a update
Re: Hi Senaka Send you a update
Hi Senaka Thanks for
Good article Senaka. Rajika
Re: Good article Senaka. Rajika