#google-cloud-platform #erlang #mnesia #google-cloud-networking #google-vpc
#google-облачная платформа #erlang #mnesia #google-облачные сети #google-vpc
Вопрос:
Я пытаюсь подключить две виртуальные машины Erlang (работающие на Centos 8, Erlang / OTP 23), одну, расположенную на GCP us-east1-b, и другую GCP europe-west6, обе внутри одного и того же VPC, работающие в отдельных подсетях, us-east 10.33.0.0 / 16 eur-west на 10.88.0.0 / 16. Маршруты и брандмауэры GCP должны быть настроены так, чтобы разрешать трафик через эти подсети и по всему VPC. Ping работает от виртуальной машины к виртуальной (см. Ниже). Telnet работает на erlang epmd порт 4369. ПРОБЛЕМА — при подключении компьютера к компьютеру с помощью утилиты erlang ping net_adm:ping() / 1 — возвращает «pang», что означает, что соединение не выполняется.
Любые предложения или мысли о том, какие могут быть проблемы, очень ценятся!!!
Вот дополнительные исследования и факты о настройках.
ОБРАТИТЕ ВНИМАНИЕ — правила брандмауэра GCP, обратите внимание, что сеть GCP «блокирует» результат при тестовом подключении, и обратите внимание, что ответы TELNET для портов 35539 и 42257 не подключаются (что, возможно, объясняет, почему виртуальные машины возвращают «pang» или не могут подключиться)
[g@app-server1-east ~]$ erl -name ack1@10.33.0.2 -setcookie whale
Erlang/OTP 23 [erts-11.1.3] [source] [64-bit] [smp:2:2] [ds:2:2:10] [asy
nc-threads:1] [hipe]
Eshell V11.1.3 (abort with ^G)
(ack1@10.33.0.2)1> net_adm:ping('ack2@10.88.0.2').
pang
(ack1@10.33.0.2)2>
[g@app-server1-east ~]$ ping 10.88.0.2
PING 10.88.0.2 (10.88.0.2) 56(84) bytes of data.
64 bytes from 10.88.0.2: icmp_seq=1 ttl=64 time=105 ms
64 bytes from 10.88.0.2: icmp_seq=2 ttl=64 time=103 ms
64 bytes from 10.88.0.2: icmp_seq=3 ttl=64 time=104 ms
64 bytes from 10.88.0.2: icmp_seq=4 ttl=64 time=103 ms
64 bytes from 10.88.0.2: icmp_seq=5 ttl=64 time=103 ms
^C
--- 10.88.0.2 ping statistics ---
6 packets transmitted, 5 received, 16.6667% packet loss, time 12ms
rtt min/avg/max/mdev = 103.290/103.749/105.243/0.754 ms
[g@app-server1-east ~]$ epmd -names
epmd: up and running on port 4369 with data:
name ack1 at port 35539
[gbaird@app-server1-east ~]$ telnet 10.88.0.2 4369
Trying 10.88.0.2...
Connected to 10.88.0.2.
Escape character is '^]'.
exit
Connection closed by foreign host.
[g@app-server1-east ~]$ telnet 10.88.0.2 42257
Trying 10.88.0.2...
telnet: connect to address 10.88.0.2: Connection timed out here
[g@app-server2-eur ~]$ erl -name ack2@10.88.0.2 -setcookie whale
Erlang/OTP 23 [erts-11.1.3] [source] [64-bit] [smp:2:2] [ds:2:2:10] [asyn
c-threads:1] [hipe]
Eshell V11.1.3 (abort with ^G)
(ack2@10.88.0.2)1> node
(ack2@10.88.0.2)1> .
node
(ack2@10.88.0.2)2>
g@app-server2-eur ~]$ ping 10.33.0.2
PING 10.33.0.2 (10.33.0.2) 56(84) bytes of data.
64 bytes from 10.33.0.2: icmp_seq=1 ttl=64 time=105 ms
64 bytes from 10.33.0.2: icmp_seq=2 ttl=64 time=103 ms
64 bytes from 10.33.0.2: icmp_seq=3 ttl=64 time=103 ms
64 bytes from 10.33.0.2: icmp_seq=4 ttl=64 time=103 ms
^C
--- 10.33.0.2 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 10ms
rtt min/avg/max/mdev = 103.194/103.601/104.685/0.666 ms
[g@app-server2-eur ~]$ epmd -names
epmd: up and running on port 4369 with data:
name ack2 at port 42257
[gbaird@app-server2-eur ~]$ telnet 10.33.0.2 4369
Trying 10.33.0.2...
Connected to 10.33.0.2.
Escape character is '^]'.
exit
Connection closed by foreign host.
[g@app-server2-eur ~]$ telnet 10.33.0.2 35539
Trying 10.33.0.2...
telnet: connect to address 10.33.0.2: Connection timed out
[gbaird@app-server2-eur ~]$
Комментарии:
1. Попробуйте бегать
net_kernel:verbose(1)
в оболочке. Это может дать вам лучшее сообщение об ошибке.
Ответ №1:
EPMD Erlang (Erlang Port Mapper Daemon) прослушивает порт 4369, но узел прослушивает случайный порт.
При настройке кластера узел регистрирует свой порт в EPMD локального хоста и связывается с EPMD удаленного хоста, чтобы запросить фактический порт для удаленного узла, после чего трафик направляется непосредственно на этот порт. EPMD — это не реле.
Вы можете управлять диапазоном портов для прослушивания узлов с помощью конфигурации ядра, в частности с inet_dist_listen_min
помощью и inet_dist_listen_max
, позволяя им в FW
Комментарии:
1. Спасибо! Похоже, что порт 4369 подключается правильно, но порт со случайным более высоким номером [35539] не подключается [см. Ответ telnet ]. Как вы думаете, это проблема с брандмауэром или сетью? что попытка виртуальной машины установить связь через [35539] не происходит, потому что соединение TCP / IP не проходит?
2. @GordonBaird Да, я так думаю, вы можете проверить с помощью wireshark (или tshark для сред терминалов), чтобы узнать, доходят ли какие-либо пакеты до узла / проверить ответ ICMP