Computer Science University Use Case

1. OpenNebula
TechDay
24 de Mayo de 2018
inLab FIB
Daniel Sánchez Dorado

2. Presentación de la FIB
2
La Facultad de Informática de Barcelona de la Universidad
Politécnica de Barcelona imparte 3 grados i 7 masters.
El inLab se encarga de dar soporte para que los alumnos
puedan desarrollas sus estudios.
Actualmente contamos con unos
• 2100 estudiantes
• 450 PCs
• 20 Salas de Laboratorios informáticos
• 100 servidores entre físicos y virtuales
• 1100 puntos de red

3. Retos: Necesidades a cubrir
3
Per cubrir las necesidades de los alumnos/desarrolladores , hasta
ahora teníamos:
• Instancias de servicios (virtual host apache virtual, BD mysql,
Oracle, ...), jenkins, tomcat, etc..
• Acceso desde el exterior limitado.
Pero … en el siglo XXI, nos damos cuenta de que los alumnos
tienen necesidades nuevas. Para ello están usando Amazon
Cloud Computing (AWS) per hacer sus prácticas. (en algunos
casos incluso pagando)
Para asignaturas necesitan servidores
• abiertos 24x7 (accesible desde Internet)
• operativos 24x7
• software diverso y único por usuario
Per desarrolladores inLab
• Lo mismo para hacer pruebas de software.

4. Descubrimos una nueva palabra mágica: cloud privado
4
• Crear un cloud privado: Una manera de tener servidores
para cada necesidad.
• Estudio de mercado: OpenStack, CloudStack, OpenNebula
• OpenNebula es una solución de cloud privado que permite
que los usuarios creen/destruyan/gestionen máquinas
virtuales a partir de plantillas. Se pueden definir
restricciones de uso y diferentes privilegios a los usuarios.
• Docència: https://virtech.fib.upc.edu
• InLab: https://skylab.fib.upc.edu

5. Malas decisiones
5
• Una vez decidido que lo que necesitamos es un cloud privado,
escogemos OpenNebula básicamente por su sencillez.
…pero...nunca es tan fácil ….
• Primera decisión errónea: montar OpenNebula y usar
servidores ESXi como nodos host
– Estaba disponible en OpenNebula 4.x
– Entrar poco a poco, con el conocimiento acumulado de ESXi
– Solución: usar nodos Linux con KVM
• Segunda decisión errónea: usar host virtuales.
– No disponemos de servidores físicos para dedicar
exclusivamente, así que haremos host virtuales.
– Nested virtualization. ¡No todos los procesadores lo admiten! No
es lo mejor, pero es necesario…
– Sorpresa: La licencia gratuita de ESXi sólo admite nodos de 8
CPUs  hemos de crear n nodos pequeños

6. Buenas decisiones
6
Creamos el nodo gestor OpenNebula en virtual. Necesita muy
poca memoria. Discos publicados por NFS
Creamos un par de nodos host de prueba y vamos creciendo
Para distinguir entre tantos servidores, adoptamos una política
sencilla:
• Los nodos de virtech tienen nombre de razas de perro: galgo,
dogo, bernardo, carlino, labrador…
• Los nodos de skylab tiene nombre de razas de gatos: angora,
siames, …
… y el resto es historia

7. Servicio para alumnos: virtech
7
• Puesta en marcha: Septiembre 2016
• Estado actual: asignaturas de grado i master.
• Direccionamiento interno UPC i a través VPN.
• DATOS:
– 1 servidor orquestación
– 6 hosts (6 “chuchos”). 2 físicos, 4 virtuales
– Total memoria disponible: 303 GB
– Total CPU disponible: 50 CPUs
– Total disco disponible: 2 TB
– Usuarios definidos: 76, de 4 asignaturas
• La demanda actual está en el límite nominal de nuestros
recursos (estamos muriendo de éxito)
• Profesores y alumnos están muy satisfechos (o eso nos
dicen…)

8. Servicio inLab : skylab
• Puesta en marcha: Abril 2017
• Estado actual: diferentes evaluaciones de proyectos.
• Direccionamiento interno inLab con un firewall.
• DATOS:
– 1 servidor orquestación
– 2 hosts (2 “gatos”), ambos virtuales
– Total memoria disponible: 20 GB
– Total CPU disponible: 12 CPUs
– Total discs disponible: 250 GB
8

9. Experiencias de uso
• Septiembre de 2016. Puesta en macha del servicio beta 1
plantilla sencilla (Ubuntu 14) con sólo 1 CPU 1GB RAM y
10 instancias.
– apt-update deja la máquina inoperativa
– Errores contextualización
– Falta software
– Generación DNS
• Febrero de 2017. Entramos en producción. Los usuarios
pueden crear 2 máquinas sencillas o 1 más grande.
– Con ½ CPU y 750 MB de RAM cubrimos sus necesidades
9

10. Experiencias de uso
• Septiembre 2017. Explosión de la demanda.
– Nos piden máquinas más grandes, con uso gráfico, 3GB
RAM, etc.. Las peticiones exceden nuestros recursos, así que
ampliamos servidores, memoria, CPU y disco
• Es un servicio que está a punto de morir de éxito
10

11. Uso actual: ¿mis recursos cubren las necesidades?
11

12. Lecciones aprendidas
• Hacemos una ampliación con 2 servidores físicos y 1 virtual
• El principal problema es la reserva de CPU y memoria que
hace cada máquina virtual una vez definida.
• Las máquinas paradas ocupan recursos. Pedimos a los
profesores que optimicen la creación de máquinas
• Estamos estudiando hacer overcommitment
• Creamos máquinas en Thin provisioning
• Para generar gráficas persistentes, hemos implementado
contadores
• Compra máquina: preferible muchos procesadores medios
a ‘Xeones’.
– Ejemplo: PowerEdge R430, 8 CPUs, 128GB RAM (error!)
• Pero ¿cuál es el uso real?
12

13. Uso real
vs
uso esperado
13

14. Poltergeist …
• El uso de memoria entre 6 nodos ¿no debería estar balanceado?
14

15. Poltergeist …
• La carga de CPU sí parece equilibrada
15

16. Poltergeist …
• ¿Existe relación entre el número de usuarios y la carga?
16

17. Nuevos retos
• Integración con Microsoft Azure
• Integración con Amazon
• Plantillas más sofisticadas
17

18. Membres de l’equip
18
• Responsables del projecte
Daniel Sánchez Dorado Sandra Marsà Hernández

19. Més informació
https://www.fib.upc.edu/ca/la-fib/serveis-tic/cloud-docent-fib
inlab@fib.upc.edu
+34 93 401 69 41
C/Jordi Girona 1-3
Campus Nord. Edifici B6
08034 Barcelona
Twitter: @inLabFIB
19