When WSO2 products are deployed in a clustered mode on Amazon EC2 instances, it is recommended to use the AWS clustering mode. As a best practice, it is recommended to add all nodes in a single cluster to the same AWS security group.
To enable AWS clustering mode, you must edit the clustering section in the
<PRODUCT_HOME>/repository/conf/axis2/axis2.xml file. When enabling AWS clustering mode, it is imperative that you do the steps in this topic, in addition to the steps you follow in the Setting up a Cluster topic for other configuration files.
<PRODUCT_HOME>/repository/conf/axis2/axis2.xml file and do the following changes.
- Enable clustering for this server.
<clustering class="org.wso2.carbon.core.clustering.hazelcast.HazelcastClusteringAgent" enable="true">
- Set the membership scheme to
awsto enable the AWS registration method.
- Specify the port used to communicate cluster messages. This must be any port number between 5701 and 5800.
Specify the IP of the instance in the
localMemberHost>element. This must be set to the IP address bound to the network interface used to communicate with other members in the group. Here's an example:
Define the following AWS specific configurations. These are the AWS access key, secret key, security group, region (with or without the zone), tag key, and tag value. The AWS credentials and security group depend on your configurations in the Amazon EC2 instance. The
tagValueare optional and the rest of the following parameters are mandatory. The
Tip: In order to provide specific permissions to create an access key and secret key for only this AWS clustering attempt, use the following custom policy block. Attach this to the user account that will operate AWS clustering in WSO2 products. The access key and secret key can only be used to list EC2 instance details in the AWS account.
You can use the following link as a reference on how to add the custom IAM policy: http://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html
For AWS clustering to work properly, you must set a specific tag key with a tag value for all EC2 instances that belong in the same cluster.
Start the server as per the instructions in the Setting up a Cluster topic. If the cluster is set up successfully, you should not see any errors when the server starts up, and also see the following log message.
When new members join the cluster, you should see messages similar to the following.
When members leave the cluster, you should see messages similar to the following.
All nodes having the same set of cluster configuration parameters will belong to the same cluster. Hazelcast calls the AWS APIs and gets a set of nodes that satisfy the specified parameters (
When the WSO2 product server starts up, it creates a Hazelcast cluster. At that point, it calls EC2 APIs and gets the list of potential members in the cluster. To call the EC2 APIs, it requires the AWS credentials. This is the only time these credentials are used. AWS APIs are only used on startup to learn about other potential members in the cluster.
Once the EC2 instances are retrieved, Hazelcast will try to connect to potential members that are running on the same port as its localMember port. By default this port is 5701. If that port is open, it will try to do a Hazelcast handshake and add that member if it belongs to the same cluster domain (group). The new member will repeat the process of trying to connect to the next port (i.e., 5702 by default) in increments of 1, until the next port is not reachable.
The following is the pseudocode for this.
Subsequently, the connections established between members are point to point TCP connections. Member failures are detected through a TCP ping. So, once the member discovery is done, the rest of the interactions in the cluster are same as when the multicast and WKA (Well Known Address) modes are used.
With that facility, you are not required to provide any member IP addresses or hostnames, which may be impossible on an IaaS such as EC2.
Note: This scheme of trying to establish connections with open Hazelcast ports from one EC2 instance to another does not violate any AWS security policies because the connection establishment attempts are made from nodes within the same security group to ports that are allowed within that security group.
Note: To enable logs in Hazelcast, set the Hazelcast log level to
FINEST in the
com.hazelcast.level = FINEST
Note: When configuring this for WSO2 API Manager 2.0.0 and more recent versions, you must configure ciphers for this in the
<APIM_HOME>/repository/conf/tomcat/catalina_server.xml file. This is done so that the AWS ELB can communicate with the WSO2 API Manager. The following is a sample configuration.
Note: The WSO2 server needs to access the AWS endpoint ec2.<region>.amazonaws.com. For example, ec2.us-east-1.amazonaws.com. Therefore, if you need a proxy to connect to the Internet, set the proxy values in
wso2server.sh as follows:
wso2server.sh, each and every http/s call goes through the proxy. To avoid this, set the
Note: You might have to import the Amazon endpoint certificates to the client truststore of the WSO2 servers.