Page Comparison

This This topic illustrates how to cluster WSO2 Governance Registry instances and how to provide database sharing for the clustered environment. Nginx has been used as the load balancer for this cluster. The following sections contain all the configurations required to configure Governance Registry instances and Nginx.

...

1. Open the <GREG_HOME>/repository/conf/axis2/axis2.xml file and do the following changes.

   1. Enable clustering for all the Governance Registry instances by setting the following entry in the axis2.xml file to true.

      Code Block
      language xml
      <clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent" enable="true">

   2. Set the membership scheme to wka to enable the well-known address registration method (this node will send cluster initiation messages to WKA members that we will define later): 

      Code Block
      language xml
      <parameter name="membershipScheme">wka</parameter>

   3. Specify the name of the cluster this node will join:

      Code Block
      language xml
      <parameter name="domain">wso2.governance.domain</parameter>

   4. Specify the host used to communicate cluster messages. You may run into issues when using host names in products based on WSO2 Carbon 4.2.0, so it is recommended that you use the IP address directly here. You can also use IP address ranges here. For example, 192.168.1.2-10.
      

      Code Block
      language xml
      <parameter name="localMemberHost">192.168.1.2</parameter>

       

   5. Specify the port used to communicate cluster messages. This port number will not be affected by the port offset in carbon.xml. If this port number is already assigned to another server, the clustering framework will automatically increment this port number. However, if two servers are running on the same machine, you must ensure that a unique port is set for each server. As a best practice, specify a unique localMemberPort for each Governance Registry node.
      

      Code Block
      language xml
      <parameter name="localMemberPort">4250</parameter>

   6. Change the subDomain property value in axis2.xml file. WSO2 Carbon-based products support a deployment model where the architecture components are separated as management nodes, which deploy artifacts and change configurations, and worker nodes, which process requests. However, because there is no service artifact deployment in Governance Registry, the nodes are not separated and are all treated identically. So, in short, there is no concept of worker/manager separation in Governance Registry clusters. In a clustered setup, you must configure this explicitly in the axis2.xml file.

      Code Block
      language xml
      <parameter name="properties"> <property name="backendServerURL" value="https://${hostName}:${httpsPort}/services/"/> <property name="mgtConsoleURL" value="https://${hostName}:${httpsPort}/"/> <property name="subDomain" value="mgt"/> </parameter>

   7. In the axis2.xml file, you must add well-known member nodes for each Governance Registry instance that you have configured. If you have three instances with 4250, 4251 and 4252 configured as their respective localMemberPort and if you are configuring the 4250 instance, then the configuration should be as follows. This reflects that the other two Governance Registry instances are defined as the well-known members.

      Code Block
      language xml
      <members> <member> <hostName>192.168.1.3</hostName> <port>4251</port> </member> <member> <hostName>192.168.1.4</hostName> <port>4252</port> </member> </members>

2. If you run multiple Governance Registry instances on the same server, avoid port conflicts by changing the <Offset> value in the <GREG_HOME>/repository/conf/carbon.xml file for each subsequent node. The offset value basically increments the port number of each instance. For example, set it to 1 in the second node to increment the port numbers by 1 and set it to 2 in the third node to increment the port numbers by 2.

   Code Block
   language xml
   <Offset>1</Offset>

3. Add host names in the <GREG_HOME>/repository/conf/carbon.xml file in each instance respectively. Once again, you can use the IP address here instead of an actual host name.

   Code Block
   language xml
   <HostName>192.168.1.2</HostName> <MgtHostName>192.168.1.2</MgtHostName>

4. Configure the HTTP/HTTPS proxy ports to communicate through the load balancer. To do this, edit the <GREG_HOME>/repository/conf/tomcat/catalina-server.xml file as shown below.

   Code Block
   language xml
   <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="9763" proxyPort="80" ... <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="9443" proxyPort="443" ...

5. Map the host name to IP by adding an entry similar to the following in the /etc/hosts file.

   Code Block
   192.168.1.2 governance.cluster.wso2.com

...

The WSO2_SOCIAL_DB social database is used to persist data of Store-side social activities (e.g., comments, rating, likes etc.). Follow the steps below to share it among Do the following configurations in each WSO2 G-Reg node, to share the social database among all the nodes of the WSO2 G-Reg cluster.

1. If you did not already create a database driver, create it as follows:

   1. Download the driver JAR file of the respective RDBMS type form the vendor's website.
   2. Copy the driver JAR file to the <G-REG_HOME>/repository/components/lib directory. 
2. Update the WSO2_SOCIAL_DB datasource, which is defined in the <G-REG_HOME>/repository/conf/datasources/social-datasources.xml file, based on your requirements. 

3. Optionally, create a query adapter. 

   Tip

   By default, WSO2 G-

   Reg is shipped with

   Reg ships the following query adapters, where org.wso2.carbon.social.db.adapter.GenericQueryAdapter is the default query adapter.

   DB Type	Query Adapter
   H2	org.wso2.carbon.social.db.adapter.GenericQueryAdapter
   MySQL	org.wso2.carbon.social.db.adapter.GenericQueryAdapter
   MSSQL	org.wso2.carbon.social.db.adapter.MSSQLQueryAdapter
   Oracle11g	org.wso2.carbon.social.db.adapter.Oracle11gQueryAdapter
   PostgreSQL	org.wso2.carbon.social.db.adapter.GenericQueryAdapter

    

   If you are using

   a different DB other than the above

   another DB type, create a query

   adapter as follows:

   adapter to support storing data in that DB type as follows.

   1. Create a custom query adapter by extending the GenericQueryAdapter and implementing the AdapterInterface.

   2. Create a JAR file for the custom query adapter.

   3. Add the query adapter into the <G-REG_HOME>/repository/components/lib directory.

4. The default If you are using another DB type other than H2 or MySQL, replace the default org.wso2.carbon.social.db.adapter.GenericQueryAdapter query adapter is used for H2 and MYSQL. If you are using another DB type, replace the default  query adapter in the <G-REG_HOME>/repository/conf/social.xml file, with the query adapter that corresponds to your DB, as shown in the example below. 

   Code Block
   <SocialConfig> <QueryAdapterClass>org.wso2.carbon.social.db.adapter.GenericQueryAdapter</QueryAdapterClass> </SocialConfig>

5. Restart the WSO2 G-Reg servers.

Now, you can view the data of the Store-side social activities (e.g., comments, rating, likes etc.) you perform in one WOS2 G-Reg node from the other nodes of the cluster.

Configuring the Nginx load balancer

...