R не может сделать кластер (многоузловой) из-за невозможности открыть ошибку подключения

Я пытаюсь запустить R параллельно, что отлично работает на локальном хосте. Теперь я хочу переключиться на многоузловую настройку и создать несколько виртуальных машин в одной сети. Однако, когда я пытаюсь настроить кластер, происходит сбой со следующей ошибкой:

Error in socketConnection(master, port = port, blocking = TRUE, open = "a+b",  : 
cannot open the connection
Calls: <Anonymous> ... doTryCatch -> recvData -> makeSOCKmaster ->
socketConnection
In addition: Warning message:
In socketConnection(master, port = port, blocking = TRUE, open = "a+b",  :
ubuntu-r-node1:11056 cannot be opened

Минимальный воспроизводимый пример:

library("parallel")
cl <- makeCluster(c(rep("192.168.42.26",2),rep("192.168.42.32",2)),outfile = "")

Я также попытался просто открыть сокет на локальном хосте, и он также не работает (но работает только кластер на локальном хосте) с тем же сообщением об ошибке:

socketConnection("localhost", port = 11056, blocking = TRUE, open = "a+b")

Только если я добавлю параметр server = TRUE, socketConnection работает, но я не уверен, подходит ли этот параметр для makeCluster и как его установить.

У меня новая установка Ubuntu Server 16.04, правила iptables пустые (ПРИНИМАЮТ все), ssh работает в обоих направлениях, поэтому я понятия не имею, почему он не работает.


r cluster-computing parallel-processing snow
person Andrey Sapegin    schedule 13.01.2017    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Ошибка socketConnection возникает, когда рабочий процесс пытается подключиться к основному процессу, вероятно, потому, что по крайней мере один из рабочих процессов не может разрешить имя хоста мастера, которое в вашем примере «ubuntu-r-node1». Имя хоста мастера определяется с использованием Sys.info()['nodename'] по умолчанию, и если кто-либо из рабочих не сможет разрешить это имя, они не смогут создать сокетное соединение с мастером, и makeCluster зависнет.

Распространенным решением этой проблемы является использование параметра makeCluster "master" для указания IP-адреса машины, на которой выполняется мастер. Вот способ сделать это с помощью функции nsl (которая недоступна в Windows) для поиска имени хоста мастера на мастере, а не на рабочих:

cl <- makePSOCKcluster(c(rep('192.168.42.26', 2),
                         rep('192.168.42.32', 2)),
          master=nsl(Sys.info()['nodename']),
          outfile='')

Указав IP-адреса как для рабочих, так и для главного, у вас будет гораздо меньше проблем с проблемами DNS. В этом примере мастер запустит воркеры, перейдя по ssh к «192.168.42.26» и «192.168.42.32», а воркеры вернутся к мастеру, используя socketConnection со значением, возвращаемым nsl(Sys.info()['nodename']).

Обратите внимание, что параметр makeCluster «port» также может быть важен, если у мастера есть брандмауэр, поскольку по умолчанию порт выбирается случайным образом в диапазоне от 11000 до 11999.

person Steve Weston    schedule 15.01.2017

arrow_upward
2
arrow_downward

Если здесь есть проблема с брандмауэром, то в качестве альтернативы:

library("parallel")
workers <- c(rep("192.168.42.26",2), rep("192.168.42.32",2))
cl <- makeCluster(workers, outfile = "")

что эквивалентно:

cl <- makePSOCKcluster(workers, outfile = "")

вы можете попробовать использовать:

library("future")
cl <- makeClusterPSOCK(workers, revtunnel = TRUE, outfile = "", verbose = TRUE)

Последний настроит так называемый обратный SSH-туннель, который будет «внутренней» частью исходящего SSH-соединения от мастера к рабочему. Если брандмауэр препятствует обратному подключению рабочих процессов к мастеру parallel::makePSOCKcluster(), например, из-за того, что диапазон портов заблокирован, то future::makeClusterPSOCK(..., revtunnel = TRUE) решает эту проблему. Вывод verbose=TRUE должен показать что-то вроде:

Starting worker #1 on '192.168.42.26': 'ssh' -R 11356:localhost:11356 192.168.42.26 "'Rscript' --default-packages=datasets,utils,grDevices,graphics,stats,methods -e 'parallel:::.slaveRSOCK()' MASTER=localhost PORT=11356 OUT= TIMEOUT=2592000 XDR=TRUE"
Waiting for worker #1 on '192.168.42.26' to connect back
Connection with worker #1 on '192.168.42.26' established
[...]

Это показывает, что, насколько известно этому рабочему процессу 192.168.42.26, он подключается обратно к главному процессу, который, по его мнению, выполняется на той же машине (MASTER=localhost:11356), что происходит, потому что обратный туннель SSH (-R 11356:localhost:11356) сопоставляет порт с этой машины. обратно к мастеру через соединение SSH.

Если этот подход обратного туннелирования не работает для вас, я думаю, вам следует обратиться к системному администратору за более подробной информацией о том, какие порты заблокированы и т. д.

Я надеюсь в этом есть смысл.

person HenrikB    schedule 07.03.2017
comment
Спасибо за ответ. Проблема уже решена (была проблема с DNS, я разместил ее как отдельный ответ), но предоставленная вами информация действительно очень полезна, я не знал о опции revtunnel. - person Andrey Sapegin; 07.03.2017

arrow_upward
0
arrow_downward

Кажется, DNS тоже должен работать в обе стороны.

Например, если первый хост (192.168.42.26) в моем примере будет иметь имя «host1», а второй хост (192.168.42.32) — «host2», то оба

ssh host1

(от хост2)

и

ssh host2

(от хост1)

должен работать для запуска кластера R.

person Andrey Sapegin    schedule 13.01.2017