26 may

Presentación Apache Mesos

Despúes de las explicaciones llegó la presentación, podeis obtener mas información en:

  1. ¿Qué es Apache-Mesos?
  2. ¿Cómo instalar Apache-Mesos?
  3. Apache-Mesos

 

26 may

Presentación Marathon Framework para Apache Mesos

Más información en

1.- Marathon framework para Apache-Mesos

2.- Balanceo de servicios con Marathon en Mesos

12 abr

Balanceo de servicios con Marathon en Mesos

Dentro de la temática de los últimos post sobre Mesos, esta vez vamos a explicar como conseguir balanceo de servicios con Marathon en Mesos o sea tener un montón de servicios corriendo a través de Marathon en nuestro cluster de Mesos y poder trabajar con ellos a lo unisono.

Primero de todo debemos ver donde esta el problema, tenerlo claro para entender la solución.

Imaginemos que tenemos un servidor web, como hemos explicado en los post anteriores este servicio puede correr en cualquier puerto en cualquier nodo del cluster, es mas podemos tener mil servicios iguales en el mismo nodo corriendo en diferentes puertos. Como es de esperar esto hace muy difícil poder utilizarlos todos como si fuera uno solo (idea principal)

Vamos a verlo en una imagine

Balanceo de servicios con Marathon en Mesos

Balanceo de servicios con Marathon en Mesos

  1. Tenemos dos Slaves
  2. Tenemos los servicios (SVC 1 y 2) corriendo en los puertos 31000 y 31200, como sabemos estoy puertos son asignados aleatoriamente por Marathon.
  3. Nos interesa que cuando accedamos al puerto X este nos envíe a uno de los servicios (SVC) que este corriendo en el cluster.

Ahora que vemos la problemática vamos a ver como al solucionamos, al lío!

Balanceo de servicios con Marathon en apache mesos

Nota: Debemos quedarnos con la idea, la solución propuesta nos puede gustar más o menos

Instalaremos un HAProxy en cada nodo de Slave, Marathon nos ofrece un script que nos facilita la solución.

Instalación balanceo de servicios

Descargamos e instalamos en cada nodo el siguiente script, lo que hace es conectarse a la api de Marathon para sacar información de en qué puerto esta corriendo los servicios.


wget https://raw.githubusercontent.com/mesosphere/marathon/master/bin/haproxy-marathon-bridge

Necesita saber las urls y puertos donde esta corriendo Marathon, en nuestro caso esta en los nodos master, para ello crearemos un fichero y pondremos la información

/etc/haproxy-marathon-bridge/marathons

Y añadimos

marathon1.company.com:8080
marathon2.company.com:8080
marathon3.company.com:8080

Por último, deberemos añadir un cron que se ejecute cada minuto, de tal manera que se conecte a la API de Marathon vea en que puertos esta corriendo nuestros servicios y nos lo añada a la configuración de HA proxy.

./haproxy-marathon-bridge install_cronjob

Vamos a ver un ejemplo de como funciona esta solución.

Primero de todo os explico la situación inicial, para que podáis entender rápidamente el gif que hay mas abajo.

Balanceo de servicios con Marathon en Mesos

Balanceo de servicios con Marathon en Mesos

Tenemos un json que nos crea en el cluster de Mesos instancias http con python a través de Marathon, en la situación inicial tenemos 1 instancia corriendo únicamente.

Haremos incrementar el numero de instancias a 10, de tal manera que tendremos 10 instancias en el cluster corriendo en puertos aleatorios, y veremos como la configuración de HAProxy se actualiza con las nuevas instancias.

Por último veremos como atacando al puerto 8080 (puerto que decidimos donde queríamos tener el servicio corriendo), veremos el slave host, donde estamos atacando y veremos como se van balanceando las peticiones.

Tendremos

  • Panel 0 : Donde lanzaremos el curl para incrementar el numero de instancias.
  • Panel 1 : Número de servicio http que tenemos en un salve, situación inicial 1
  • Panel 2 : Curl al servicio web donde veremos como entre en el balanceo un nuevo salve.
  • Panel 3 : Configuración de HAProxy
Balanceo de servicios con Marathon en Mesos

Balanceo de servicios con Marathon en Mesos

Como podemos ver, con esta solución lo que conseguimos es poder escalar nuestras aplicaciones sin necesidad de “preocuparnos” del puerto en el que esta corriendo.

El concepto cambia, escalamos aplicaciones, no escalamos servidores para montar aplicaciones.

Ahora reflexionemos sobre ello.

16 mar

Marathon framework para Apache-Mesos

Después de explicar qué es Apache-Mesos y cómo se instala llega el momento de poner a funcionar el sistema, para ello lo que vamos a instalar es Marathon y lo utilizaremos para correr aplicaciones en los slaves de Apache-Mesos.

Pues vamos al lio

¿Qué es Marathon?

Marathon es un framework que corre junto a Mesos y que nos permite lanzar a través de él aplicaciones de larga duración, o sea que vayan a estar tiempo dando servicio, por ejemplo un Apache, servicios Python …, viene siendo un init para el cluster de Mesos, a más a más dispone de una API que hace la gestión realmente sencilla.

¿Cómo se instala Marathon?

Siguiendo con la arquitectura de los post anteriores, tenemos en nuestras maquinas Centos añadidos los repositorios de Mesosphere, asi pues que la instalacion es tan sencilla como lanzar en todos los masters del cluster de Mesos el siguiente comando

yum install marathon

Al utilizar el paquete que nos da Mesosphere la configuración es automática, por defecto nos utilizara el mismo ZooKeeper que tenemos configurado para Mesos.

Únicamente me encontré con un problema a la hora de configurarlo y fue que me hacia falta cambiar el puerto por el cual estaba escuchando ya que se solapaba con otros servicios, esto se hace de una forma muy fácil.

Las opciones que nos encontramos en http://mesosphere.github.io/marathon/docs/command-line-flags.html se activan creando un fichero de configuración de la siguiente manera, por ejemplo para modificar el puerto por el cual escucha

cat /etc/marathon/conf/http_port
7070

¿Cómo se trabaja con Marathon?

Una vez instalado comprobamos que el servicio esta corriendo.

marathon.service - Marathon
Loaded: loaded (/usr/lib/systemd/system/marathon.service; enabled)
Active: active (running) since Sun 2015-03-15 09:14:58 UTC; 7min ago
Main PID: 1352 (java)
CGroup: /system.slice/marathon.service
├─1352 java -Djava.library.path=/usr/local/lib -Djava.util.logging.SimpleFormatter.format=%2$s%5$s%6$s%n -Xmx512m -cp /usr/local/bin/marathon mesosphere.marathon.Main --http_port 7070 --zk zk://172.3...
├─1368 logger -p user.info -t marathon[1352]
└─1369 logger -p user.notice -t marathon[1352]

Tenemos dos formas de trabajar, a través de una web o por command line.

Interfaz web

Para conectarnos a Marathon iremos a la ip de nuestro master y el puerto por defecto 8080.

Veremos algo tal que así, en mi caso ya dispongo de algunas tareas corriendo.

marathon

Por la interfaz web podemos hacer cosas muy sencillas, por ejemplo si le damos a New App nos permitirá lanzar una aplicación con algunos parámetros base.

marathon2

Por ejemplo podemos hacer una tarea que lace un echo y se espere 5 segundos, como hemos dicho, Marathon se asegurara que esa tarea siempre este corriendo en el cluster de Mesos, a más a más como explicamos en los post anteriores nos asegurará que tendremos los recursos que nos hacen falta, en este caso un 10% de la cpu disponible 16MB de Ram y sin disco necesario.

marathon task

Como hemos dicho sin nos fijamos en el gif, esta tarea tiene un final, pero el cluster se encargara de que siempre este funcionando, cuando se detecte que la tarea se finalizo se volverá a lanzar.

runAPP.gif

Si le damos encima de la aplicación podemos ver datos muy interesantes como por ejemplo, cuando se lanzo, en que nodo del cluster se encuentra o que versión esta desplegada. Cada cambio que apliquemos en las condiciones que queremos que corra nuestra aplicación (por ejemplo aumentarle la RAM) será una nueva versión, de tal manera que podremos volver atrás en las configuraciones.

Información de la tarea

infotaskConfiguración

configure

 

Hasta aquí la parte sencilla, ahora vamos al command line y vamos a explicar como se mueven las aplicaciones por el cluster.

Marathon como no podría ser de otra manera tiene una API para gestionar las tareas, las peticiones sobre las tareas nuevas o ya existentes se realizan envío de ficheros json, tenemos diferentes opciones todas están descritas aquí.

Vamos a poner ejemplo de las más comunes.

Creación y modificación de aplicaciones a través de la REST API.

Lo primero es generar un json con las opciones que queramos, en la doc oficial podemos ver que pueden tener un montón de opciones diferentes. https://mesosphere.github.io/marathon/docs/rest-api.html#post-/v2/apps

Aquí voy a poner unos cuantos ejemplos y explicaré las opciones que me resultaron mas útiles.

Ports

{
"cmd": "echo `hostname` test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0",
"id": "/python",
"instances": 3,
"mem": 0.001,
"cpus": 0.001,
"disk": 0,
"ports": [
80
]
}

Este es muy sencillo, pero es interesante ver como podemos pasar un puerto a la lina de ejecución, en este caso nos interesa que nuestro servidor HTTP siempre se ejecute en el puerto 80, esta característica será imperativo para que la aplicación pueda correr en un slave, o sea que dicho slave tenga el puerto 80 libre. Con esto nos permite poder correr diferentes servidores web en el cluster. La variable $PORT0 será un puerto aleatorio que asignara mesos, cuando explique la alta disponibilidad de Marathon veremos como podemos saber ese puerto en todo momento.

HealthChecks

"healthChecks":[
{
"protocol":"TCP",
"gracePeriodSeconds":3,
"intervalSeconds":5,
"portIndex":1,
"timeoutSeconds":5,
"maxConsecutiveFailures":3
}

Podemos asignar HeathCheck a la tarea, por defecto cuando el pid de la tarea desaparece se da por finalizada y se vuelve a lanzar, pero como sabemos esto no siempre es significativo, podemos entonces verificar el funcionamiento de nuestra aplicación a través de un check TCP o una respuesta HTTP

upgradeStrategy

"upgradeStrategy": {
"minimumHealthCapacity": 1
},

Esta opción es muy interesante, con ella le diremos el número mínimo de instancias que debe haber en el caso que realicemos un cambio de configuración, cuando se realiza dicho cambio las tareas se vuelven a lanzar, imaginemos que tenemos 100 apaches, y queremos aumentarle la memoria, en el caso que no hubiéramos puesto esta opción nos encontraríamos que el cluster apagaría todas las instancias para volver a lanzarlas con la nueva configuración.

uris y env

{
"cmd": "env ; /tmp/env ; gzip -d server.gz ; bash server $PORT0",
"cpus": 0.2,
"id": "artifact",
"instances": 1,
"mem": 1,
"disk": 15000,
"backoffSeconds": 1,
"upgradeStrategy": {
"minimumHealthCapacity": 1
},
"tasksRunning": 3,
"tasksStaged": 0,
"ports": [
0
],
"uris": [
"http://172.30.0.145/server.gz"
],
"env": {
"TEST": "ENVIO DE VARIABLE"
}

Como explicamos en los post anteriores cuando lanzamos una tarea Mesos crea un nuevo container, este nuevo espacio aislado tiene sus propias variables de entorno, estas variables se las podemos pasar como vemos en el ejemplo, la  variable TEST.

A más a más dentro del proceso de desligue de la aplicación le podemos decir que se descarga algo de una web, por ejemplo el código de la aplicación. ;)

Constraints

{
"id": "kafka",
"cmd": "/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/server.properties",
"mem": 12,
"cpus": 0.001,
"instances": 1,
"constraints": [
["hostname", "UNIQUE"]
]
}

Nos puede interesar tener diferentes servicios en diferentes nodos del cluster, por ejemplo si tenemos un mysql corriendo no nos interesara que los slaves y el master puedan estar en la misma máquina, UNIQUE es nuestro amigo.

Vamos a ver como lanzamos una tarea.

Crearemos una sencilla, un servidor python que correrá en cualquier puerto, la linea de hostname no es necesaria, pero es útil para cuando expliquemos el HA de marathon, le decimos que nos arranque 3 instancias.

{
"cmd": "echo `hostname` ; test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0",
"id": "/zpython",
"instances": 3,
"mem": 0.001,
"cpus": 0.001,
"disk": 0,
"ports": [
80
]
}
curl -H "Content-Type: application/json" -d @python.json http://localhost:7070/v2/apps

Como podemos ver en el gif la tarea se crea y se despliegan 3 instancias

deployAPP.gifSi nos vamos a la web del cluster de Mesos vermeos las tareas corriendo.

runtask

 

Escalada de aplicaciones 

Imaginemos que ahora en vez de 3 necesitariamos 100, pues la cosa seria tan sencilla como modificar la opcion instance y volver a lanzar el curl.

{
"cmd": "echo `hostname`; test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0",
"id": "/zpython",
"instances": 50,
"mem": 0.001,
"cpus": 0.001,
"disk": 0,
"ports": [
80
]
}
curl -H "Content-Type: application/json" -d @python.json http://localhost:7070/v2/apps

Como podéis ver los valores de mem y cpu no tienen sentido, pero los puse asi para que podamos crear aplicaciones sin control.

scalationAPP.gif

Esto es una maravilla a mi parecer.

50

Una vez creadas las 50 tareas, si nos conectamos a un slave como se reparten con un simple ps

[[email protected] centos]# ps aux | grep python
root 471 0.0 0.5 549976 18140 ? Ssl 08:59 0:00 /usr/bin/python -Es /usr/sbin/tuned -l -P
root 24059 0.0 0.0 115216 1472 ? Ss 10:33 0:00 sh -c echo `hostname` >> test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0
root 24062 0.0 0.2 201072 9676 ? S 10:33 0:00 /usr/bin/python -m SimpleHTTPServer 31631
root 24283 0.0 0.0 115216 1472 ? Ss 10:41 0:00 sh -c echo `hostname` >> test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0
root 24286 0.0 0.2 201072 9676 ? S 10:41 0:00 /usr/bin/python -m SimpleHTTPServer 31394
root 24301 0.0 0.0 115216 1468 ? Ss 10:41 0:00 sh -c echo `hostname` >> test.txt ; /usr/bin/python -m SimpleHTTPServer $PORT0
root 24304 0.0 0.2 201072 9680 ? S 10:41 0:00 /usr/bin/python -m SimpleHTTPServer 31905

Podemos ver como se han ido asignando puertos “aleatorios” en los servicios, si hacemos una petición a ese puerto buscando el fichero test.txt nos deberá dar el hostname de la maquina donde esta corriendo.

[[email protected] centos]# curl localhost:31842/test.txt
ip-172-30-0-116.us-west-2.compute.internal

Si queremos volver a dejar todo como estaba el procedimiento es el mismo, cambiamos el 50 por 3 y listos.

decrecerAPP
Vamos a ver que pasaría en el caso que uno de nuestros servicios python dejará de funcionar repentinamente, ya que dijimos que siempre deberíamos tener 50 corriendo.

killAPP

Como podemos ver es muy rapida.

Por último vamos a ver donde podemos encontrar nuestras aplicaciones dentro de los slaves, si no le hemos dicho lo contrario todos los contenedores son creados en /tmp.

Si nos vamos a ese nivel y hacemos un find del fichero txt podremos ver lo siguiente.

[[email protected] mesos]# find . -name test.txt
./slaves/20150315-085909-1862278828-5050-809-S1/frameworks/20150109-162856-2449481388-5050-10637-0000/executors/python.504a72d9-caf2-11e4-82c6-0233785b9264/runs/72d62e43-101c-4e20-89b6-f0b93b1baa94/test.txt
./slaves/20150315-085909-1862278828-5050-809-S1/frameworks/20150109-162856-2449481388-5050-10637-0000/executors/python.53d3e7ba-caf2-11e4-82c6-0233785b9264/runs/3798405d-b0d4-40ed-9939-7b29eb40c68b/test.txt
./slaves/20150315-085909-1862278828-5050-809-S1/frameworks/20150109-162856-2449481388-5050-10637-0000/executors/python.c2094b5c-caf3-11e4-8d09-02f82bce2403/runs/6c67ef7b-1bac-44cf-850e-209b99517c08/test.txt
...
[[email protected] mesos]# pwd
/tmp/mesos

La ruta que vemos es el mismo identificador que vemos en la pagina de Mesos Cluster
taskid

 

En el siguiente post explicaremos como montar HA para las aplicaciones de Marathon.

22 feb

¿Cómo instalar Apache-Mesos?

En el post anterior explicamos qué es Mesos y como funciona internamente, así que, como no puede ser de otra manera, toca instalarlo.

La mejor manera que encontré de instalar Apache-Mesos es utilizando los paquetes de mesosphere.

Nuestro excenario inicial es:

  • 3 servidores Mesos master y ZooKeeper cluster
  • 3 servidores mesos slave
  • Centos 7
  • Y lo montaremos en EC2

Pues al lío.

Empezarnos por los nodos master, estos pasos los debemos hacer en todos los nodos master que tengamos

Instalación de paquetes

Añadimos el repositorio

sudo rpm -Uvh http://repos.mesosphere.io/el/7/noarch/RPMS/mesosphere-el-repo-7-1.noarch.rpm

Actualizamos

yum update

Instalamos Mesos

sudo yum -y install mesos

Instalamos zookeeper

sudo yum -y install mesosphere-zookeeper

Configuración de ZooKepeer

Antes de nada deberemos configurar ZooKepeer, deberemos añadir un numero diferente en cada servidor master, entre el 1 y el 255, en nuestro caso lo añadiremos en

/var/lib/zookeeper/myid

Ahora en todos los nodos de ZooKepeer deberemos decirle donde estan los otros nodos del cluster, esto se hace de la siguiente manera.

vi /etc/zookeeper/conf/zoo.cfg

Añadimos con las ips correctas

server.1=1.1.1.1:2888:3888
server.2=2.2.2.2:2888:3888
server.3=3.3.3.3:2888:3888

Y arrancamos ZooKepeer

sudo systemctl start zookeeper

Configuración de Mesos

Estos pasos también los haremos en todos los miembros master del cluster

Configuramos Mesos para que trabaje con ZooKeeper

vi /etc/mesos/zk

Añadimos las ips de los servidores de ZooKepeer

zk://1.1.1.1:2181,2.2.2.2:2181,3.3.3.3:2181/mesos

Defeninimos el quorum que queremos

vim /etc/mesos-master/quorum
2

Por ultimo debilitamos el servicio de mesos-slave que se nos instalo con el paquete y arrancamos mesos-master.

systemctl stop mesos-slave.service
systemctl disable mesos-slave.service
sudo service mesos-master restart

Comprobamos que el servicio este levantado correctamente.

<pre> systemctl status mesos-master -l
mesos-master.service - Mesos Master
   Loaded: loaded (/usr/lib/systemd/system/mesos-master.service; enabled)
   Active: active (running) since Sun 2015-02-15 11:22:50 UTC; 7min ago
 Main PID: 1156 (mesos-master)
   CGroup: /system.slice/mesos-master.service
           ├─1156 /usr/sbin/mesos-master --zk=zk://172.30.0.111:2181,172.30.0.145:2181,172.30.0.146:2181/mesos --port=5050 --log_dir=/var/log/mesos --quorum=1 --registry=in_memory --work_dir=/var/lib/mesos
           ├─1168 logger -p user.info -t mesos-master[1156]
           └─1169 logger -p user.err -t mesos-master[1156]

Feb 15 11:26:03 ip-172-30-0-111.us-west-2.compute.internal mesos-master[1169]: I0215 11:26:03.540731  1171 master.cpp:1263] The newly elected leader is [email protected]:5050 with id 20150205-134012-1862278828-5050-813
Feb 15 11:26:08 ip-172-30-0-111.us-west-2.compute.internal mesos-master[1169]: I0215 11:26:08.747304  1175 http.cpp:478] HTTP request for '/master/state.json'
Feb 15 11:26:12 ip-172-30-0-111.us-west-2.compute.internal mesos-master[1169]: I0215 11:26:12.015610  1176 detector.cpp:138] Detected a new leader: (id='51')
Feb 15 11:26:12 ip-172-30-0-111.us-west-2.compute.internal mesos-master[1169]: I0215 11:26:12.015688  1176 group.cpp:659] Trying to get '/mesos/info_0000000051' in ZooKeeper
Feb 15 11:26:12 ip-172-30-0-111.us-west-2.compute.internal mesos-master[1169]: I0215 11:26:12.016731  1176 detector.cpp:433] A new leading master ([email protected]:5050) is detected
Feb 15 11:26:12 ip-172-30-0-111.us-west-2.compute.internal mesos-master[1169]: I0215 11:26:12.016767  1176 master.cpp:1263] The newly elected leader is [email protected]:5050 with id 20150215-111558-2432704172-5050-808
Feb 15 11:26:19 ip-172-30-0-111.us-west-2.compute.internal mesos-master[1169]: I0215 11:26:19.730078  1171 http.cpp:478] HTTP request for '/master/state.json'
Feb 15 11:26:27 ip-172-30-0-111.us-west-2.compute.internal mesos-master[1169]: I0215 11:26:27.725008  1171 http.cpp:344] HTTP request for '/master/redirect'
Feb 15 11:27:12 ip-172-30-0-111.us-west-2.compute.internal mesos-master[1169]: I0215 11:27:12.129428  1170 http.cpp:344] HTTP request for '/master/redirect'
Feb 15 11:30:02 ip-172-30-0-111.us-west-2.compute.internal systemd[1]: Started Mesos Master.

La salida de systemctl me parece de lo mas interesante, podemos ver información muy útil, como por ejemplo los nodos de zookeeper o quien es el líder del cluster “Detected a new leader”. 

A más a más, Apache-Mesos dispone de una interfaz web, a la cual podemos acceder por el puerto 5050 y veremos cosas como esta.

main

Podemos ver información, casi en tiempo real de la situación del cluster, vemos los recursos utilizados y disponibles, las tareas activas etc etc, si quisiéramos podemos incluso ver el log del sistema (también esta en /var/log/mesos)

main3En la pestaña Slaves también podemos ver (obvio) el estado de los slaves, que recordemos que son los responsables de ejecutar las tareas.

main2Y por ultimo los Frameworks que tenemos registrados, en nuestro caso tenemos Marathon, un framework muy interesante que explicaré en las siguientes entradas.

 





15 feb

¿Qué es Apache-Mesos?

mesos

Este es el primero de una serie de post donde explicaré:

  1. ¿Cómo funciona Mesos?
  2. ¿Cómo se instala?
  3. ¿Cómo se instalan Frameworks?
  4. ¿Cómo se lanzan aplicaciones en el cluster a través de Marathon?
  5. ¿Cómo se escalan esas aplicaciones?

Mesos nos ofrece una capa de abstracción entre los servidores y los recursos, es un concepto un poco diferente, pero a mi parecer cuando lo entiendes me parece excepcioal. Por otro lado Mesos te proporciona una gestión de cluster y como una una gestión de los recursos del cluster.

O sea que básicamente lo que tendremos es un lugar donde correr nuestras aplicaciones (Frameworks, después explicamos que es esto) sin preocuparnos de los servidores que tenemos por debajo.

¿Qué ofrece Mesos?

  1. Escalabilidad hasta 10000 nodos
  2. Alta disponibilidad de los servidores Master y los servidores Slaves a traves de Zookeeper
  3. Soporta de forma nativa Docker
  4. Aislamiento de recursos entre procesos en el cluster, o sea que que aseguramos que no se pisen entre ellos o que no puedan acceder los unos a los otros.
  5. Podemos desarollar Frameworks  en Java, Python y C++.

Esta es la teoría por encima, a partir de aquí viene la parte técnica

Venga al lío.

Funcionamiento de Apache-Mesos

Mesos

Esta es la estructura básica para tener un cluster de mesos, donde tendremos:

1.- Tres Mesos master, uno en activo y dos en Standby

2.- Tres Zookeepers

3.- Tres Mesos Slave

Nodos masters

Dentro del un cluster de Mesos tendremos los nodos Master, de todos los que podamos tener solo uno será el que este en activo, los demás estarán en una posición pasiva, a la espera de que el nodo activo pueda fallar y entonces asumir el role de master activo, esta flujo de trabajo se realiza a través de zookeeper, que es  el punto de unión de los nodos Master, a través del cual todos saben el estado del resto de nodos master.

Nodos slaves

Los nodos slaves son los encargados de correr las tareas de los Frameworks, estos reportan su estado directamente al nodo master activo, ya que saben cual es a través de zookeeper.

Frameworks

Los Frameworks  son instalados en los nodos master, y a través de ellos trabajaremos con los recursos de los slaves, estos se puede desarrollar a nuestro antojo http://mesos.apache.org/documentation/latest/app-framework-development-guide/ o utilizar los que ya existen

Frameworks

http://mesos.apache.org/documentation/latest/mesos-frameworks/

Pongamos un ejemplo para entenderlo mejor, imaginemos que optamos por un Framework  de Big Data Processing por ejemplo Storm, pues instalaremos el storm-mesos en los masters, cuando queramos hacer una petición se lo realizaremos al Framework, que a su vez hablara con el master y este se encargara de enviar la tarea a uno o varios slaves. Estas tareas puede ser de corta o larga duración.

¿Cómo funciona las peticiones de recursos?

architecture-example

El funcionamiento es sencillo

  1. Pongamos que el framework 1 solicita recursos para lanzar dos tareas (la cual puede ser un cron o un servicio como Jboss y Apache o Storm, etc etc …)
  2. Los nodos slaves reportan al master el número de recursos libres que disponen, en nuestro ejemplo el slave 1 le comenta al master que tiene 4cpu y 4gb libres.
  3. Cuando el framework pide recursos, el master le dice que tiene  4cpu y 4gb disponibles, entonces el framework envía las tareas con el los recursos necesarios.
    1. Task 1, 2 cpu 1gb
    2. Task 2, 1cpu 2gb

4. El master se encarga de enviar las tareas a los slaves (mesos-executor) y este las empieza a ejecutar.

5. Si un segundo Framework solicita recursos, el master sabe que aún le sobra 1cpu y 1gb en el slave 1.

¿Cómo funciona internamente los slaves?

isolation

Como hemos comentado  las tareas que se lanzan en los slaves estas aisladas, este aislamiento por defecto se hace con cgroups linux, también docker de forma nativa, cuando la tarea llega al slave, este crea un nuevo recurso cgroups y se lo asigna a la tarea.

Pongamos un caso practico, imaginemos que tenemos una replica de mysql corriendo en un slave, con el paso del tiempo esta repica tendra datos, caches y de mas informaicón necesaria para que el servicio corra, entonces podemos pensar que en el caso que el slave falle seria un problema.

Para eso Mesos ofrece una serie de paliativos.

Checkpoints

  • Los slaves realizan checkpoints sobre el estado de la tarea, son como copias de seguridad del estado, para que en el caso que tengamos que reiniciar el slave la recuperación sea mas rápida.

Cache executor

  • En el caso de que el servicio de mesos-slave no este disponible, las nuevas tareas y peticiones serán guardadas en una cache, cuando el servicio este recuperado se empezaran a tramitar

Conexion

  • Una tarea que ya se ejecuto anteriormente tendrá mas posibilidades de volverse a ejecutar en el mismo cgroups y el mismo slave que lo hizo la ultima vez, de esta manera la información se podrá recuperar.

Fallo del salve

  • En el caso de fallo completo de un slave, el framework solicitará volver a montar la tarea en un nuevo slave.

En el siguiente post explicare como se instala Apache-Mesos en Centos7

 Referencias

http://mesos.apache.org/