Post on 28-Jul-2018
Jornadas Técnicas de RedIRIS 2014 (Cáceres)
Sistema automático de creación de nodos de cómputo virtuales en la nube
Alfonso Pardoalfonso.pardo@ciemat.es
¿Quiénes somos?
San Francisco Convent2
¿Quiénes somos?❖ CETA-CIEMAT: Es una iniciativa conjunta del Gobierno de España y el Gobierno
de Extremadura.
San Francisco Convent2
¿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
San Francisco Convent2
¿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:
San Francisco Convent2
¿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:
San Francisco Convent2
❖ GRID, HPC y cloud.
❖ Contribuir la expansion de la e-Ciciencia
❖ Facilitar el uso de recursos.
¿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 IaaS
Servidores físicos
7
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 pre-configurados 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 pre-configurados 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 pre-configurados 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
15
Sin acelerar
Resultados
15
Con 10maquinas virtuales
Sin acelerar
¡GRACIAS!
¿Alguna pregunta?
CETA-Ciemat agradece la aportación del Fondo Europeo de Desarrollo Regional
16