linux - Punto final de transporte no conectado-Mesos Slave/Master

debian virtualbox

Question

Estoy tratando de conectar un esclavo Mesos a su amo. Cuando el esclavo intenta conectarse al maestro, aparece el siguiente mensaje:

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

El error parece ser:

E0806 16: 39: 59.091384 940 socket.hpp: 107] Error de apagado en fd = 25: el punto final de transporte no está conectado [107]

El host se inició utilizando:

./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

Y el esclavo

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

Si ejecuto el esclavo en la misma máquina virtual que el host, está funcionando bien.

No pude encontrar mucha información en internet. Estoy ejecutando dos cajas virtuales (Debian 8.1) en VirtualBox 5. El host es un Windows 7.

Edición 1:

El maestro y el esclavo se ejecutan en una máquina virtual dedicada.

Ambas VMs nextorks están configuradas utilizando una red puenteada.

ifconfig de 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 de esclavo:

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)

Edición 2:

Los registros de esclavos se pueden encontrar en http://pastebin.com/CXZUBHKr

Los registros maestros se pueden encontrar en http://pastebin.com/thYR1par

Answer 1

Ejecute el esclavo con --ip=10.129.62.49 en --ip=10.129.62.49 lugar

Answer 2

Me he encontrado con este error en los registros al actualizar las versiones de mesos (por ejemplo, 0.20.0 -> 0.27.0). A veces los datos de la versión anterior son incompatibles con otras versiones.

Aquí es cómo lo remedié:

Primero asegúrese de que todos los nodos tengan el servicio mesos-master detenido:

sudo service mesos-master stop

Luego borra todos los datos antiguos potenciales:

1. Eliminar $MESOS_WORK_DIR ( /var/mesos en mi caso):

   sudo rm -rf /var/mesos

2. Borrar nuestros datos de mesos en ZooKeeper:

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

Después de realizar estos pasos, inicié el servicio mesos-master en todos los nodos y volvió a estar en línea.

Answer 3

Tuve un problema similar. Mis registros de esclavos estarían llenos de

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

Mi maestro tendría

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

Y el maestro moriría, y se produciría una nueva elección, el maestro muerto sería reiniciado por el inicio (estoy en una casilla de Centos 6) y se agregaría al grupo de maestros potenciales. Por lo tanto, mi maestro elegido se encadenaría alrededor de mis nodos maestros. Muchos reinicios de amos y esclavos no hicieron nada, el problema volvería sistemáticamente dentro de 1 minuto de la elección de maestro.

La solución para mí provino de una pregunta de este flujo de pila (gracias) y una sugerencia en una nota de github.

La esencia de esto es /etc/default/mesos-master debe especificar un número de quórum (debe ser correcto para el número de maestros de mesos, en mi caso 3)

    MESOS_QUORUM=2

Esto me parece extraño ya que tengo la misma información en el archivo /etc/mesos-master/quorum

Pero lo agregué a /etc/default/mesos-master reinicié mesos-masters y slaves y el problema no ha regresado.

Espero que esto te ayude.

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

Esta es la sugerencia de error.

Tu esclavo expone la IP equivocada.

--ip=10.129.62.49 al comando esclavo y funciona.