How does it work?
It is important to understand how communication between the Paralllels Plesk Automation Management Node (MN) and Service Nodes work. All nodes have a public IP (frontnet) and private IP (backnet or communication IP address) and these IP addresses are used according to the scheme below:
Determine which IP address is used as public and which is used for communication between nodes. This can be done using the following two methods:
To find this on the MN, run the command below (NOTE: use a non-existent file name, because if you select an existing file with defined IP mapping, the utility will try to change IP addresses on your MN without confirmation):
~# /usr/local/ppa/bin/ppa.ip_address /tmp/new_file
Check this file to find the communication IP address:
# cat /tmp/someuniqname # You should edit IP addresses to reflect your future settings. Old main ip=10.39.87.15 New main ip=10.39.87.15 Old communication ip=192.168.0.15 New communication ip=192.168.0.15
As you can see, address 192.168.0.15 is used for communication by the MN.
For example, you tried to deploy a node, the task failed and you want to find which IP address was used as the backnet (communication) IP. To determine which IP address was selected for communication on the Service Node, you should find out which address is listening on port 8352:
# netstat -ntpl | grep 8352 tcp 0 0 192.168.0.13:8352 0.0.0.0:* LISTEN 30878/pleskd
C:\>netstat -ano | findstr :8352 tcp 0 0 192.168.0.16:8352 0.0.0.0:* LISTEN
As you can see, IP addresses 192.168.0.13 and 192.168.0.16 are listening on port 8352. This means they are used as communication IP addresses on the Service Nodes.
After you have found the communication IP address (e.g. 192.168.0.13), you can use the
check_service_nodeutility to check Service Node availability:
~# /usr/local/ppa/bin/check_service_node --ip 192.168.0.13
It is important to use the communication IP address to check.
What can be wrong?
There may be cases when:
check_service_nodedoes not show errors, but Service Node deployment still fails.
check_service_nodedoes not work at all, but the Service Node is reachable and can be deployed.
When you deploy a new node, the following should be mandatory:
- The Service Node communication IP address should be reachable from your MN.
- Requests to the Service Node communication IP address should come from your MN communication IP (192.168.0.15)
This is important because firewall rules are created for communication IP addresses on nodes, and if requests are not coming from these addresses (because of incorrect routing), they are blocked:
Chain PPA-SN-Rules-INPUT (2 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 192.168.0.15 0.0.0.0/0 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0
In a common issue, you use private IP addresses on the MN and Service Node, but routing is configured incorrectly. This means the Service Node address is reachable by ping, but requests are not coming from the private address of the MN.
You can check this in the following way:
On the Management Node, run
~# tcpdump -pn -i any -vvA port 80
From the Service Node, run telnet to 192.168.0.15 (the MN communication IP):
~# telnet 192.168.0.15 80
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 09:41:03.128202 IP (tos 0x10, ttl 64, id 39372, offset 0, flags [DF], proto: TCP (6), length: 60) 10.39.87.13.49912 > 192.168.0.15.http: S, cksum 0x1a10 (correct), 1968665456:1968665456(0) win 14600 <mss 1460,sackOK,timestamp 2612062908 0,nop,wscale 7>
As you can see, the request came from IP address 10.39.87.13, not from 192.168.0.13. As a result, it was blocked by the firewall (because access to port 8352 is only allowed for the communication IP address 192.168.0.13).