Jornadas Técnicas de RedIRIS 2014 (Cáceres)

Sistema automático de creación de nodos de cómputo virtuales en la nube

Alfonso Pardo [email protected]

¿Quiénes somos?

2

San Francisco Convent

¿Quiénes somos? ❖

CETA-CIEMAT: Es una iniciativa conjunta del Gobierno de España y el Gobierno de Extremadura.

2

San Francisco Convent

¿Quiénes somos? ❖

CETA-CIEMAT: Es una iniciativa conjunta del Gobierno de España y el Gobierno de Extremadura.

❖

Es una institución pública financiada por PGE y FEDER

2

San Francisco Convent

¿Quiénes somos? ❖

CETA-CIEMAT: Es una iniciativa conjunta del Gobierno de España y el Gobierno de Extremadura.

❖

Es una institución pública financiada por PGE y FEDER

❖

Misión: Consolidar y diseminar la e-Ciencia y las IT, especialmente la GRID y las e-Infraestructuras:

2

San Francisco Convent

¿Quiénes somos? ❖

CETA-CIEMAT: Es una iniciativa conjunta del Gobierno de España y el Gobierno de Extremadura.

❖

Es una institución pública financiada por PGE y FEDER

❖

Misión: Consolidar y diseminar la e-Ciencia y las IT, especialmente la GRID y las e-Infraestructuras: ❖

GRID, HPC y cloud.

❖

Contribuir la expansion de la e-Ciciencia

❖

Facilitar el uso de recursos.

2

San Francisco Convent

¿Quiénes somos?

3

¿HPC? ❖

HPC: High performance computing

❖

Resolución de problemas de gran envergadura usando paralelismo.

❖

Grupo de nodos de cómputo trabajando a la vez para resolver un problema/s.

4

5

❖

Un cluster dispone de una serie de nodos fijos.

5

❖

Un cluster dispone de una serie de nodos fijos.

❖

Está gobernado por un gestor de recursos.

5

❖

Un cluster dispone de una serie de nodos fijos.

❖

Está gobernado por un gestor de recursos. ❖

TOP 500:

5

❖

Un cluster dispone de una serie de nodos fijos.

❖

Está gobernado por un gestor de recursos. ❖

❖

TOP 500: Ampliación del cluster para afrontar mayores trabajos o procesar un mayor número de estos requiere adquirir nuevo hardware (y más dinero) y reconfigurar el cluster.

5

¿Cloud?

6

¿Cloud?

❖

¿De verdad a estas alturas es necesario definirla?

6

¿Cloud?

❖

¿De verdad a estas alturas es necesario definirla?

❖

IaaS (Infrastructure as a service). Poder crear maquinas virtuales a petición. Nuestra elección:

6

Unificando conceptos

7

Unificando conceptos ❖

Yo tengo un cluster que quiero ampliar, y tu tienes una cloud para ofrecerme máquinas virtuales.

7

Unificando conceptos ❖

Yo tengo un cluster que quiero ampliar, y tu tienes una cloud para ofrecerme máquinas virtuales.

❖

Poder levantar nodos de cluster en IaaS para ampliar el cluster.

7

Unificando conceptos ❖

Yo tengo un cluster que quiero ampliar, y tu tienes una cloud para ofrecerme máquinas virtuales.

❖

Poder levantar nodos de cluster en IaaS para ampliar el cluster.

❖

Pero: ¿Cómo? y ¿Cuándo?

7

Unificando conceptos ❖

Yo tengo un cluster que quiero ampliar, y tu tienes una cloud para ofrecerme máquinas virtuales.

❖

Poder levantar nodos de cluster en IaaS para ampliar el cluster.

❖

Pero: ¿Cómo? y ¿Cuándo?

Servidores físicos

Alta demanda

Servidores7 físicos

IaaS

8

❖

Cuándo: En momentos puntuales de alta carga. Necesitaremos alguien o algo que nos diga cuándo sucede esto.

8

❖

Cuándo: En momentos puntuales de alta carga. Necesitaremos alguien o algo que nos diga cuándo sucede esto.

❖

Cómo: Mediante el uso de API para levantar máquinas pre-configuradas. Necesitaremos alguien o algo que haga esta llamada automáticamente por nosotros.

8

❖

Cuándo: En momentos puntuales de alta carga. Necesitaremos alguien o algo que nos diga cuándo sucede esto.

❖

Cómo: Mediante el uso de API para levantar máquinas pre-configuradas. Necesitaremos alguien o algo que haga esta llamada automáticamente por nosotros.

❖

¿Y después? Eliminar la máquina cuando ya no es necesaria. Necesitaremos alguien que haga este trabajo sucio por nosotros.

8

¿Quién hará todo esto?

9

¿Quién hará todo esto? ❖

Necesitaremos un agente que sea “consciente” de la carga del cluster es el gestor de colas (SLURM).

9

¿Quién hará todo esto? ❖

Necesitaremos un agente que sea “consciente” de la carga del cluster es el gestor de colas (SLURM).

❖

Otro agente será el encargado de levantar/destruir máquinas según sean necesarias o no.

9

¿Quién hará todo esto? ❖

Necesitaremos un agente que sea “consciente” de la carga del cluster es el gestor de colas (SLURM).

❖

Otro agente será el encargado de levantar/destruir máquinas según sean necesarias o no.

9

¿Cómo?

10

¿Cómo? 1.El gestor de colas envía trabajos a los nodos, por lo que es “consciente” del indice de carga y del estado de las colas.

10

¿Cómo? 1.El gestor de colas envía trabajos a los nodos, por lo que es “consciente” del indice de carga y del estado de las colas. 2.El gestor de colas tiene una serie de nodos virtuales dados de alta en estado “no disponibles”.

10

¿Cómo? 1.El gestor de colas envía trabajos a los nodos, por lo que es “consciente” del indice de carga y del estado de las colas. 2.El gestor de colas tiene una serie de nodos virtuales dados de alta en estado “no disponibles”. 3.Una aplicación desarrollada por el CETA-CIEMAT sondea el estado de las colas y de la carga, gracias a la información facilitada por el gestor de colas.

10

¿Cómo? 1.El gestor de colas envía trabajos a los nodos, por lo que es “consciente” del indice de carga y del estado de las colas. 2.El gestor de colas tiene una serie de nodos virtuales dados de alta en estado “no disponibles”. 3.Una aplicación desarrollada por el CETA-CIEMAT sondea el estado de las colas y de la carga, gracias a la información facilitada por el gestor de colas. 4.Cuando la carga o el número de trabajos supera cierto umbral, levantar nodos preconfigurados en la Cloud mediante API.

10

¿Cómo? 1.El gestor de colas envía trabajos a los nodos, por lo que es “consciente” del indice de carga y del estado de las colas. 2.El gestor de colas tiene una serie de nodos virtuales dados de alta en estado “no disponibles”. 3.Una aplicación desarrollada por el CETA-CIEMAT sondea el estado de las colas y de la carga, gracias a la información facilitada por el gestor de colas. 4.Cuando la carga o el número de trabajos supera cierto umbral, levantar nodos preconfigurados en la Cloud mediante API. 5.El gestor de colas detecta estos nuevos nodos al levantarse y los añade.

10

¿Cómo? 1.El gestor de colas envía trabajos a los nodos, por lo que es “consciente” del indice de carga y del estado de las colas. 2.El gestor de colas tiene una serie de nodos virtuales dados de alta en estado “no disponibles”. 3.Una aplicación desarrollada por el CETA-CIEMAT sondea el estado de las colas y de la carga, gracias a la información facilitada por el gestor de colas. 4.Cuando la carga o el número de trabajos supera cierto umbral, levantar nodos preconfigurados en la Cloud mediante API. 5.El gestor de colas detecta estos nuevos nodos al levantarse y los añade. 6.Nuevos trabajos llegan a los nodos virtuales liberando de carga al cluster físico y a las colas. 10

¿Cómo? (II)

11

¿Cómo? (II) 7. El software de gestión detecta que ha bajado la carga y marca los nodos virtuales para que no entren más trabajos en ellos.

11

¿Cómo? (II) 7. El software de gestión detecta que ha bajado la carga y marca los nodos virtuales para que no entren más trabajos en ellos. 8. El software de gestión detecta que en los nodos virtuales no hay nada en ejecución y los marca para destruirlos.

11

¿Cómo? (II) 7. El software de gestión detecta que ha bajado la carga y marca los nodos virtuales para que no entren más trabajos en ellos. 8. El software de gestión detecta que en los nodos virtuales no hay nada en ejecución y los marca para destruirlos. 9. Mediante API destruye los nodos virtuales y pone dichos nodos en el gestor de colas como “no disponibles” de nuevo.

11

¿Cómo? (II) 7. El software de gestión detecta que ha bajado la carga y marca los nodos virtuales para que no entren más trabajos en ellos. 8. El software de gestión detecta que en los nodos virtuales no hay nada en ejecución y los marca para destruirlos. 9. Mediante API destruye los nodos virtuales y pone dichos nodos en el gestor de colas como “no disponibles” de nuevo. 10.Volvemos a empezar… 11

Esquema general

12

Otras especificaciones

13

Otras especificaciones ❖

Gestor escrito en C++. Interfaces escrito en python.

13

Otras especificaciones ❖

Gestor escrito en C++. Interfaces escrito en python.

❖

Uso de un interface para la llamada a las API que lo hace compatible con cualquier cloud: Amazon, Openstack, Proxmox…

13

Otras especificaciones ❖

Gestor escrito en C++. Interfaces escrito en python.

❖

Uso de un interface para la llamada a las API que lo hace compatible con cualquier cloud: Amazon, Openstack, Proxmox…

❖

Uso de interface para consulta del gestor de colas, lo que lo hace compatible con cualquier gestor de colas: SLURM, OGE,…

13

❖

Generación de gráficas de uso (GNUPlot):

❖

Generación de gráficas de uso (GNUPlot):

❖

Configuración de umbrales de creación/destrucción de máquinas virtuales adaptable.

❖

Generación de gráficas de uso (GNUPlot):

❖

Configuración de umbrales de creación/destrucción de máquinas virtuales adaptable.

❖

Y más…

Resultados

15

Resultados Sin acelerar

15

Resultados Sin acelerar

Con 10 maquinas virtuales

15

¡GRACIAS! ¿Alguna pregunta?

CETA-Ciemat agradece la aportación del Fondo Europeo de Desarrollo Regional

16