This documentation is for older versions of WSO2 products and may not be relevant now. Please see your respective product documentation for clustering details and configurations.

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This topic provides instructions on how to configure a standard Gateway cluster for the App Manager. The instructions in this topic are based on the Clustering App Manager topic and these configurations will only work if the configurations in that topic are done correctly. For instance, all datasource configurations are already done for the Gateway in that topic and hence do not need to be repeated here.

Warning

Important: It is recommended that you use IP addresses instead of host names when configuring clustering for WSO2 products. This is due to the version of Hazelcast used.

The following sections provide specific instructions on configuring the Gateway cluster.

Table of Contents
maxLevel43
minLevel3

Gateway deployment pattern

The configurations in this topic will be done based on the following pattern. This pattern is used as a basic Gateway cluster where the worker nodes and manager nodes are separated.

Image Removed

Expand
titleClick here to view a sample of the full API Manager cluster.

Image Removed

Image Added

Configuring the load balancer

NGINX Nginx Plus is used for this scenario, but you can use any load balancer that you prefer here. The following are the configurations that need to be done for the load balancer.

...

  1. Install Nginx using the following command.
    $sudo apt-get install nginx
  2. Configure Nginx Plus to direct the HTTP requests to the two worker nodes via the HTTP 80 port using the http://amappm.wso2.com/<service>. To do this, create a VHost file (amappm.http.conf) in the /etc/nginx/conf.d/ directory and add the following configurations into it.

    Code Block
    upstream wso2.am.com {
            sticky cookie JSESSIONID;gatewaywkhttp {
            server xxx.xxx.xxx.xx4xx3::97638280;
            server xxx.xxx.xxx.xx5xx4:97638280;
    }  server {     sticky learn create=$upstream_cookie_jsessionid
     listen 80;         server_name am.wso2.com;lookup=$cookie_jsessionid
             location / {
       zone=gw_http_sessions:1m;
    }
    server {
     	listen 80;
     server_name appm.wso2.com;
     location / {
                proxy_set_header X-Forwarded-Host $host;
    
                  proxy_set_header X-Forwarded-Server $host;
                   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                   			proxy_set_header Host $http_host;
    			proxy_read_timeout               proxy_read5m;
    			proxy_send_timeout 5m;
                   proxy_send			proxy_connect_timeout 5m;  2;
    			proxy_next_upstream     error timeout invalid_header      http_500;
    			proxy_pass http://wso2.am.comgatewaywkhttp/;
    			proxy_redirect http://gatewaywkhttp/ http://appm.wso2.com/;        
          }
    }
  3. Configure Nginx Plus to direct the HTTPS requests to the two worker nodes via the HTTPS 443 port using https://amappm.wso2.com/<service>. To do this, create a VHost file (amgateway.https.conf) in the /etc/nginx/conf.d/ directory and add the following configurations into it.

    Code Block
    upstream ssl.wso2.am.comgatewaywkhttps {
    	sticky cookie JSESSIONID;
    	server xxx.xxx.xxx.xx4xx3:94438243;
    	server xxx.xxx.xxx.xx5xx4:94438243;
    }
    sticky server {
    listenlearn create=$upstream_cookie_jsessionid
    lookup=$cookie_jsessionid
    zone=gw_https_sessions:1m;
     }
    
    server {
    isten 443;
    	server_name amappm.wso2.com;
    	ssl on;
    	ssl_certificate /etc/nginx/ssl/wrkmgt.crt;
    	ssl_certificate_key /etc/nginx/ssl/wrkmgt.key;
    	 location / {
                   			proxy_set_header X-Forwarded-Host $host;
                   			proxy_set_header X-Forwarded-Server $host;
                   			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                   			proxy_set_header Host $http_host;
    			proxy_read_timeout               proxy_read5m;
    			proxy_send_timeout 5m;
    			proxy_connect_timeout   2;
    			proxy_next_upstream     error timeout     proxy_send_timeout 5m;
    	invalid_header http_500;      proxy_pass https://gatewaywkhttps/ssl.wso2.am.com;
        				proxy_redirect https://gatewaywkhttps/ https://appm.wso2.com/;
    		 }
    }
  4. Configure Nginx Plus to access the Management Console as https://mgt.amappm.wso2.com/carbon via HTTPS 443 port. This is to direct requests to the manager node. To do this, create a VHost file (mgt.amappm.https.conf) in the /etc/nginx/conf.d/ directory and add the following configurations into it.

    Code Block
    serverupstream gatewaymgthttps {
    	listen
    443;
    	server_name mgtxxx.amxxx.wso2xxx.comxx2:9443;
    	sslsticky on;
    	ssl_certificate /learn create=$upstream_cookie_jsessionid
    lookup=$cookie_jsessionid
    zone=gw_mgt_https_sessions:1m;
    }
    
    server {
    listen 443;
    server_name mgt.appm.wso2.com;
    ssl on;
    ssl_certificate /etc/nginx/ssl/mgt.crt;
    	ssl_certificate_key /etc/nginx/ssl/mgt.key;
    
    	location / {
                   proxy_set_header X-			proxy_set_header X-Forwarded-Host $host;
                   			proxy_set_header X-Forwarded-Server $host;
                   			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                   proxy_set_header Host $http_host;
    			proxy_read_timeout               proxy_read5m;
    			proxy_send_timeout 5m;
    			proxy_next_upstream     error timeout invalid_header http_500;         proxy_sendconnect_timeout   5m2;
    	    		proxy_pass https://xxx.xxx.xxx.xx3:9443gatewaymgthttps/;
        	}
    	error_log  /var/log/nginx/mgt-error.log ;
               access_log  /var/log/nginx/mgt-access.log;
    }			proxy_redirect https://gatewaymgthttps/ https://mgt.appm.wso2.com/;
    		}
    }
  5. Restart the Nginx Plus server.
    $sudo service nginx restart

    Tip

    Tip: You do not need to restart the server if you are simply making a modification to the VHost file. The following command should be sufficient in such cases.

    $sudo service nginx reload 

...

While creating keys, enter the host name (amappm.wso2.com or mgt.amappm.wso2.com) as the Common Name.

You have now configured the load balancer to handle requests sent to amappm.wso2.com and to distribute the load among the worker nodes in the worker sub-domain of the wso2.amappm.domain cluster.

You are now ready to set up the cluster configurations. The next step is to configure the Gateway manager.

...

  1. Open <GATEWAY_MANAGER_HOME>/repository/conf/carbon.xml.
  2. Locate the <HostName> tag and add the cluster host name: 
    <HostName>am<HostName>appm.wso2.com</HostName>
  3. Locate the <MgtHostName> tag and uncomment it. Make sure that the management host name is defined as follows:
    <MgtHostName>mgt.amappm.wso2.org</MgtHostName> 

Configuring the catalina-server.xml file

...

Code Block
languagenone
<GATEWAY-WORKER-IP> amappm.wso2.com

In this example, it would look like this:

Code Block
languagenone
xxx.xxx.xxx.xx4 amappm.wso2.com

We have now finished configuring the manager node and are ready to start the Gateway manager.

...

The additional -Dsetup argument will create the required tables in the database. The above configuration runs the API Manager with all it's different components, i.e., Publisher, Store, Gateway and Key ManagerIDP. So to start this as a manager node with only Gateway functionality available, use the following command instead.

...

  1. Open <GATEWAY_WORKER_HOME>/repository/conf/carbon.xml on each worker node.
  2. Specify the host name as follows.
    <HostName>amappm.wso2.com</HostName>

You can configure the deployment synchronizer, which is also done in the carbon.xml file.

...

Code Block
languagenone
<GATEWAY-MANAGER-IP> mgt.amappm.wso2.com 

In this example, it would look like this:

Code Block
languagenone
xxx.xxx.xxx.xx3 mgt.amappm.wso2.com 

We have now finished configuring the worker nodes and are ready to start them.

...

The additional -Dprofile=gateway-worker argument indicates that this is a worker node specific to the Gateway. This parameter basically makes a server read-only. A node with this parameter will not be able to do any changes such as writing or making modifications to the deployment repository, etc. Starting this node as a Gateway worker ensures that Store and Publisher related functionality is disabled. This parameter also ensures that the node starts as the worker profile, where the UI bundles will not be activated and only the back end bundles will be activated once the server starts up. See API Manager product profiles for more information on the various product profiles available in API Manager.