R не может makeCluster (multinode) из-за ошибки «не удается открыть соединение»

Question

Я пытаюсь запустить 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") 

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

У меня есть новая установка Ubuntu Server 16.04, правила iptables пустые (ACCEPT все), ssh работает в обоих направлениях, поэтому я понятия не имею, почему это не работает.

Answer 1

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

Общей задачей для этой проблемы является использование опции «master» makeCluster для указания 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'ing до «192.168.42.26» и «192.168.42.32», и рабочие вернутся к главному, используя socketConnection со значением, возвращаемым nsl(Sys.info()['nodename']).

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

Answer 2

Кажется, что DNS также должен работать в обоих направлениях.

Например, если первый узел (192.168.42.26) в моем примере будет иметь имя 'host1' и второй узел (192.168.42.32) 'host2', то как

ssh host1 

(от host2)

и

ssh host2 

(от host1)

должны работать, чтобы запустить R кластера.

Answer 3

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

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.

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

Я надеюсь, что это имеет смысл.