TroubleShooting: Clustering API Portal - Ports

webMethods API Portal tutorial

The default standard recommendation for establishing a High availablity setup for API Portal involves 3 machines. As we know API Portal stack has multiple runtime components. Each of these runtime components uses certain ports. These ports must be open between the clustered nodes to be able to communicate with in the cluster freely. Often times customers forget to open these ports resulting in a failure.

Runtime components used in API Portal stack

1. ZooKeeper
2. Postgres
3. ElasticSearch
4. CloudSearch
5. APIBundle
6. Kibana
7. LoadBalancer

Default ports

Below table summarizes the ports used by different versions of API Portal. We need to open these ports from all 3 machines(to be on safe) in order to be able to these different components to talk to each other

Checking whether ports are open:

We can use below tools availabe in unix system to verify whether particular port from a remote machine is open

(1) /dev/tcp/host/port
If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open a TCP connection to the corresponding socket.

Example:
cat < /dev/tcp/127.0.0.1/18009

(2) Netcat

nc is the command which runs netcat, a simple Unix utility that reads and writes data across network connections, using the TCP or UDP protocol.

Succesfull execution:

nc -zv 127.0.0.1 18010
Connection to 127.0.0.1 18010 port [tcp/*] succeeded!

Failure cases:

nc -zv 127.0.0.1 18009
nc: connect to 127.0.0.1 port 18009 (tcp) failed: Connection refused

To validate a single port:

nc -zv 127.0.0.1 18009
Validates the port 18009 is open

To validate multiple ports

nc -zv 127.0.0.1 18101 18102
Validates the port 18101 and 18102 is open

To validate a range of ports

nc -zv 127.0.0.1 18000-18200
Validates the port in the range 18000 to 18200 are open.