Clustering WSO2 IoT Server

The following diagram illustrates a typical deployment pattern for WSO2 IoT Server.

As indicated in the above diagram, when clustering WSO2 IoT Server, there is worker manager separation. In a standard WSO2 product cluster, worker and manager separation is derived from deployment synchronization. However, this differs from standard WSO2 Carbon worker manager separation.

WSO2 IoT Server includes an admin console that can be used by any user with administrative privileges. These users can perform operations on enrolled devices and the devices can retrieve those actions by requesting for the pending operations. This is done by either walking the device through a push notification or configuring the device to poll at a pre-configured frequency.

Normally administrative tasks should be run from a manager node.

There are two major deployment patterns for the manager node. One could be running the manager node in the private network due to security constraints and other is allowing end users to access the management node so that they can control and view their devices.

A manager node is used to run background tasks that are necessary to update device information such as location and the list of installed applications. For more information on creating different profiles in WSO2 IoT Server, see Product Profiles.

Let's take a look at the steps to cluster WSO2 IoT Server:

Before you begin

You need the following to cluster WSO2 IoT Server:

Virtual machines used in a high availability cluster

The following is a list of virtual machines (VMs) that are used in a high availability cluster and their details.

Manager - 1 VM
Worker - 2 VMs
Key manager - 2 VMs
DBs - 1 MySQL instance

All the VMs have 4 cores and 4GB memory.

Open ports

80 and 443 are from the NGINX server.

The following ports need to be opened for Android and iOS devices so that it can connect to GCM (Google Cloud Message) and APNS (Apple Push Notification Service) and enroll to WSO2 IoT Server.

Android

The ports to open are 5228, 5229 and 5230. GCM typically uses only 5228, but it sometimes uses 5229 and 5230.

GCM does not provide specific IPs, so it is recommended to allow the firewall to accept outgoing connections to all IP addresses contained in the IP blocks listed in Google's ASN of 15169.

iOS

5223 - TCP port used by devices to communicate to APNS servers
2195 - TCP port used to send notifications to APNS
2196 - TCP port used by the APNS feedback service
443 - TCP port used as a fallback on Wi-Fi, only when devices are unable to communicate to APNS on port 5223

The APNS servers use load balancing. The devices will not always connect to the same public IP address for notifications. The entire 17.0.0.0/8 address block is assigned to Apple, so it is best to allow this range in the firewall settings.