This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Clustering Identity Server 5.1.0 and 5.2.0

Creating a cluster of WSO2 Identity Server instances involves a standard two node cluster for high availability. To ensure that the instances share governance registry artifacts, you must create a JDBC mount. At a high level, use one of the following options to cluster Identity Server with a minimum of two nodes.

Clustering IS

  1. Install Identity Server on each node. See Installing the Product for more information.
  2. Create the registry database and configure it. See Setting up the Database for more information on setting up the database and mounting the registry.

    Tip: The topic linked talks about how to configure databases and mounting the registry for manager and worker nodes. However, there is no need to separate the worker and manager nodes in the Identity Server. So when configuring this, ensure that the configurations done for the Identity Server nodes replicate those done for the manager node in that topic.

  3. Do the following changes to the <IS_HOME>/repository/conf/axis2/axis2.xml file for both nodes.

    1. Enable clustering on node 1 and node 2 by setting the clustering element to true: 
      <clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent" enable="true">

    2. Use the same domain name across the cluster.
      <parameter name="domain">wso2.is.domain</parameter>

    3. Use the well known address (WKA) based clustering method. In WKA-based clustering, we need to have a subset of cluster members configured in all the members of the cluster. At least one well known member has to be operational at all times.
      <parameter name="membershipScheme">wka</parameter> 

    4. Configure the localMemberHost and localMemberPort entries. These must be different port values for the two nodes if they are on the same server to prevent any conflicts.

      <parameter name="localMemberHost">127.0.0.1</parameter>
      <parameter name="localMemberPort">4000</parameter> 
    5. Under the members section, add the hostName and port for each WKA member. As we have only two nodes in our sample cluster configuration, we will configure both nodes as WKA nodes.

      <members>
          <member>
            <hostName>127.0.0.1</hostName>
            <port>4000</port>
          </member>
          <member>
            <hostName>127.0.0.2</hostName>
            <port>4010</port>
          </member>
      </members>

      Note: You can also use IP address ranges for the hostName. For example, 192.168.1.2-10. This should ensure that the cluster eventually recovers after failures. One shortcoming of doing this is that you can define a range only for the last portion of the IP address. You should also keep in mind that the smaller the range, the faster the time it takes to discover members since each node has to scan a lesser number of potential members.

  4. Change the datasource name to jdbc/WSO2UMDB in user-mgt.xml (located in <IS_HOME>/repository/conf/) and identity.xml (located in <IS_HOME>/repository/conf/identity) of both node1 and node2.

    user-mgt.xml
    <UserManager>
      <Realm>
      <Configuration>
      ...
      <Property name="dataSource">jdbc/WSO2UMDB</Property>
      </Configuration>
      ...
      </Realm>
    </UserManager>
    identity.xml
    <JDBCPersistenceManager>
       	 <DataSource>
       		<Name>jdbc/WSO2UMDB</Name>
       	 </DataSource>
       	    	 <!-- <SkipDBSchemaCreation>false</SkipDBSchemaCreation> -->
    </JDBCPersistenceManager>
  5. Copy the JDBC driver (in this case MySQL driver) to the <IS_HOME>/repository/component/lib directory of both nodes. To do this, download the MySQL Java connector JAR from here and place it in the <IS_HOME>/repository/components/lib directory.

  6. Point all cluster nodes to same user store (to share one LDAP directory). By default, WSO2 Identity Server is started with an embedded LDAP which comes with the product. Disable the embedded LDAP of node 2 by modifying embedded-ldap.xml which can be found in the <IS_HOME>/repository/conf/identity directory.

    <EmbeddedLDAP>
    	<Property name="enable">false</Property>
    <--------------------->
    <EmbeddedLDAP>

    Point node 2 to the default user store of node1. You need to configure the connection URL in user-mgt.xml of node2 as given below (default port is 10389). By default, the connection URL given in the file is ldap://localhost:${Ports.EmbeddedLDAP.LDAPServerPort}.

    <UserStoreManager class="org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager">
        <------------>
    	<Property name="ConnectionURL">ldap://[IP_of_node1]:10389</Property>
    	<------------>
    </UserStoreManager >

    If you are using some other external user store, make sure you point both nodes to that external user store.

  7. If both nodes will be running on the same server, set the port offset to avoid port conflicts. 

  8. Start the nodes. Use the -Dsetup option (e.g., sh wso2server.sh -Dsetup) on node 1 and node 2.
  9. Verify in the registry browser that the governance collection is shown with the symlink icon.

Fronting the IS cluster with a load balancer (Nginx)

If you need to front the above IS cluster with Nginx, you can follow the instructions given below (you must do this after setting up the cluster following the above instructions). When clustering WSO2 Identity Server with a load balancer, you may need to enable sticky sessions. This is required for the management console and the dashboard to work and iff we disable temporary session data persistence in the <IS_HOME>/repository/conf/identity/identity.xml file. It is also necessary to For more information on sticky sessions, see Sticky Sessions with Manager Nodes.

Configuring Nginx

See /wiki/spaces/CLUSTER44x/pages/9732195 for more information on configuring Nginx or Nginx Plus with WSO2 products.

Identity Server node 1 configuration

Configure the Identity Server node 1 using the following steps.

  1. Configure deployment synchronizer in carbon.xml (autocommit=false in node 2). See Configuring SVN-Based Deployment Synchronizer for more details on how to configure this.

    Note: This is optional and you only need to do this if you configure a secondary userstore manager through the management console.

    <deploymentsynchronizer>
     	<enabled>true</enabled>
     	<autocommit>true</autocommit>
     	<autocheckout>true</autocheckout>
     	<repositorytype>svn</repositorytype>
     	<svnurl>http://svnexample.wso2.com/svn/test</svnurl>
     	<svnuser>wso2</svnuser>
     	<svnpassword>wso2123</svnpassword>
     	<svnurlappendtenantid>true</svnurlappendtenantid>
    </deploymentsynchronizer>
  2. Allow access to the management console only through the load balancer. Configure the HTTP/HTTPS proxy ports to communicate through the load balancer by editing the <IS_HOME>/repository/conf/tomcat/catalina-server.xml file as follows.

    <Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
    	port="9763"
    	proxyPort="80"
    	...
    	/>
    <Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
    	port="9443"
    	proxyPort="443"
    	...
    	/>
     Click here for more information on this configuration.

    The Connector protocol tag sets the protocol to handle incoming traffic. The default value is HTTP/1.1, which uses an auto-switching mechanism to select either a blocking Java-based connector or an APR/native connector. If the PATH (Windows) or LD_LIBRARY_PATH (on most UNIX systems) environment variables contain the Tomcat native library, the APR/native connector will be used. If the native library cannot be found, the blocking Java-based connector will be used. Note that the APR/native connector has different settings from the Java connectors for HTTPS.

    The non-blocking Java connector used is an explicit protocol that does not rely on the auto-switching mechanism described above. The following is the value used:
    org.apache.coyote.http11.Http11NioProtocol

    The TCP port number is the value that this Connector will use to create a server socket and await incoming connections. Your operating system will allow only one server application to listen to a particular port number on a particular IP address. If the special value of 0 (zero) is used, Tomcat will select a free port at random to use for this connector. This is typically only useful in embedded and testing applications.

  3. In the <IS_HOME>/repository/conf/carbon.xml directory, define the hostname for your server.

    <HostName>wso2.is.com</HostName>
    
    <MgtHostName>wso2.is.com</MgtHostName>

    This hostname is used by the IS cluster. It must be specified in the /etc/hosts file as:

    127.0.0.1   wso2.is.com

Identity Server node 2 configuration

Follow all the configuration steps that were done in node 1 for node 2 as well. 

Running the cluster
  1. Start Nginx and the Identity Server nodes.
  2. Now you can access the management console using the following URL: https://wso2.is.com/carbon/