Endpoint di trasporto non connesso - Mesos Slave/Master

Question

Sto provando a connettere uno slave Mesos al suo master. Whenver lo schiavo tenta di connettersi al master, ricevo il seguente messaggio:

I0806 16:39:59.090845 935 hierarchical.hpp:528] Added slave 20150806-163941-1027506442-5050-921-S3 (debian) with cpus(*):1; mem(*):1938; disk(*):3777; ports(*):[31000-32000] (allocated:) 
E0806 16:39:59.091384 940 socket.hpp:107] Shutdown failed on fd=25: Transport endpoint is not connected [107] 
I0806 16:39:59.091508 940 master.cpp:3395] Registered slave 20150806-163941-1027506442-5050-921-S3 at slave(1)@127.0.1.1:5051 (debian) with cpus(*):1; mem(*):1938; disk(*):3777; ports(*):[31000-32000] 
I0806 16:39:59.091747 940 master.cpp:1006] Slave 20150806-163941-1027506442-5050-921-S3 at slave(1)@127.0.1.1:5051 (debian) disconnected 
I0806 16:39:59.091868 940 master.cpp:2203] Disconnecting slave 20150806-163941-1027506442-5050-921-S3 at slave(1)@127.0.1.1:5051 (debian) 
I0806 16:39:59.092031 940 master.cpp:2222] Deactivating slave 20150806-163941-1027506442-5050-921-S3 at slave(1)@127.0.1.1:5051 (debian) 
I0806 16:39:59.092248 939 hierarchical.hpp:621] Slave 20150806-163941-1027506442-5050-921-S3 deactivated 

L'errore sembra essere:

E0806 16: 39: 59,091,384 mila 940 socket.hpp: 107] Shutdown fallito il fd = 25: Trasporto endpoint non è collegato [107]

Il padrone di casa è stato avviato utilizzando:

./mesos-master.sh --ip=10.129.62.61 --work_dir=~/Mesos/mesos-0.23.0/workdir/ --zk=zk://10.129.62.61:2181/mesos --quorum=1 

E lo schiavo

./mesos-slave.sh --master=zk://10.129.62.61:2181/mesos 

Se eseguo lo schiavo sulla stessa macchina virtuale come l'host va bene lavorare.

Non ho trovato molte informazioni su Internet. Io corro due scatole virtuali (Debian 8.1) su VirtualBox 5. Il padrone di casa è un Windows 7.

Edit 1:

Il padrone e lo schiavo sia eseguito su una macchina virtuale dedicato.

Entrambe le VM nextorks sono configurate utilizzando la rete a ponte.

ifconfig da maestro:

eth0  Link encap:Ethernet HWaddr 08:00:27:cc:6c:6e 
      inet addr:10.129.62.61 Bcast:10.129.255.255 Mask:255.255.0.0 
      inet6 addr: fe80::a00:27ff:fecc:6c6e/64 Scope:Link 
      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
      RX packets:5335953 errors:0 dropped:0 overruns:0 frame:0 
      TX packets:1422428 errors:0 dropped:0 overruns:0 carrier:0 
      collisions:0 txqueuelen:1000 
      RX bytes:595886271 (568.2 MiB) TX bytes:362423868 (345.6 MiB) 

ifconfig da schiavo:

eth0  Link encap:Ethernet HWaddr 08:00:27:56:83:20 
      inet addr:10.129.62.49 Bcast:10.129.255.255 Mask:255.255.0.0 
      inet6 addr: fe80::a00:27ff:fe56:8320/64 Scope:Link 
      UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
      RX packets:4358561 errors:0 dropped:0 overruns:0 frame:0 
      TX packets:3825 errors:0 dropped:0 overruns:0 carrier:0 
      collisions:0 txqueuelen:1000 
      RX bytes:397126834 (378.7 MiB) TX bytes:354116 (345.8 KiB) 

Edit 2:

I registri slave può essere trovato alla http://pastebin.com/CXZUBHKr

I registri anagrafici sono disponibili all'indirizzo http://pastebin.com/thYR1par

Answer 1

Eseguire lo slave con --ip=10.129.62.49 invece

Answer 2

Ho avuto un problema simile. miei registri di schiavi si sarebbero riempiti di

E0812 15:58:04.017990 2193 socket.hpp:107] Shutdown failed on fd=13: Transport endpoint is not connected [107] 

mio maestro avrebbe

F0120 20:45:48.025610 12116 master.cpp:1083] Recovery failed: Failed to recover registrar: Failed to perform fetch within 1mins 

E il maestro sarebbe morto, e una nuova elezione si sarebbe verificato, il maestro ucciso sarebbe stato riavviato da parvenu (io sono su una scatola di Centos 6) ed essere aggiunto al pool di potenziali maestri. Quindi il mio eletto signore si sarebbe legato a catena intorno ai miei nodi principali. Molti riavvii di maestri e schiavi non fecero in modo che il problema tornasse consistentemente entro 1 minuto dall'elezione principale.

La soluzione per me proviene da una domanda di stackoverflow (grazie) e un suggerimento in un github gist note.

L'essenza di esso è /etc/default/mesos-master necessario specificare un numero di quorum (ha bisogno di essere corretto per il numero di Mesos maestri, nel mio caso 3)

MESOS_QUORUM=2 

Questo sembra strano per me come io ho lo stesso informazioni nel file /etc/mesos-master/quorum

Ma l'ho aggiunto a /etc/default/mesos-master riavviato il mesos-master e slave e il problema non è stato restituito.

Spero che questo ti aiuti.

Answer 3

Ho riscontrato questo errore nei registri durante l'aggiornamento delle versioni di mesos (ad esempio 0.20.0 -> 0.27.0). A volte i dati della versione precedente non sono compatibili con altre versioni.

Ecco come ho rimediato esso:

Prima assicurare tutti i nodi hanno il servizio mesos-master fermo:

sudo service mesos-master stop 

Poi chiaro fuori tutto il potenziale dei dati antiche:

1. Rimuovere $MESOS_WORK_DIR (/var/mesos nel mio caso):

   sudo rm -rf /var/mesos 
   

2. cancellare i nostri dati in Mesos ZooKeeper:

   $ zkCli.sh 
   WatchedEvent state:SyncConnected type:None path:null 
   [zk: localhost:2181(CONNECTED) 0] rmr /mesos 
   [zk: localhost:2181(CONNECTED) 0] quit 
   Quitting... 
   

Dopo avere fatto questi passi che ho iniziato il servizio mesos-master su tutti i nodi e ne è venuto di nuovo online.

Answer 4

I0806 16:39:59.091747 940 master.cpp:1006] Slave 20150806-163941-1027506442-5050-921-S3 at slave(1)@127.0.1.1:5051 (debian) disconnected 

Questo è il suggerimento di errore.

Lo slave mostra l'IP errato.

Aggiungi --ip=10.129.62.49 al comando slave e funziona.