1. Elasticidad automática basada en métricas
de servicio de aplicaciones corporativas
desplegadas en Clouds IaaS
Fermín Galán, Alonso Álvarez, Ignacio Blasco, Daniel Morán
Real Elastic Cloud (REC), Telefónica I+D
XXI Telecom I+D
Santander
28 de septiembre de 2011
0
TELEFÓNICA I+D Audiovisuales S.A. / Telefónica España S.A.
Telefónica Servicios
Título de la ponencia / Otros datos de interés / 26-01-2010
Telefónica I+D 0

2. Índice
01 Introducción
02 Elasticidad basada en métricas de servicio
03 Implementación y resultados
04 Conclusiones
Telefónica I+D 1

3. 01
Introducción
Telefónica I+D
Telefónica I+D 2

4. Cloud computing: Un concepto confuso…
computing: confuso…
Telefónica I+D 3

5. …pero en el que hay algunas cosas claras
Características fundamentales
• Autoprovisión
• Dinamicidad
• Elasticidad
• Pago por uso (CAPEX → OPEX)
• Multi-tenant
• Agilidad
Modalidades
• Software como servicio (SaaS)
› GMail, Google Docs
• Plataforma como servicio (PaaS)
› Google Apps Engine, Azure
• Infraestructura como servicio (IaaS)
› Amazon EC2
Telefónica I+D 4

6. Infraestructura como servicio y Elasticidad
Cloud IaaS
App
Virtualización
Midware
SO
Máquina virtual
Pool de servidores físicos
Telefónica I+D 5

7. Aplicaciones transaccionales multicapa
Ej. JBoss, Ej. MySQL,
Ej. Apache Tomcat Oracle
FE1 BE1
FE2 BE2
LB
DB
LB
… …
Usuarios
del
FEn BEm
servicio
Presentación Lógica de Persistencia
negocio
X App Aplicación transaccional multicapa corporativa típica
→ Midware
LB SO
Telefónica I+D 6

8. 02
Elasticidad basada en
métricas de servicio
Telefónica I+D
Telefónica I+D 7

9. Estado del arte
Elasticidad automatizada
• Basada en métricas de infraestructura
› CPU, RAM, I/O disco, tráfico de red
• Amazon Cloud Watch + Auto Scaling, RightScale, Zenos Unified Monitoring,
Tought Auto Scaling Service, etc.
180ms
50ms
70ms
App App
Midware Midware
SO 50 SO 50
0 100 0 100
CPU CPU
Telefónica I+D 8

10. Problema
Las métricas de infraestructura no gobiernan necesariamente la calidad del
servicio
• Al usuario no le importa si la CPU está cargada o no: lo que le interesa es el
cumplimiento del SLA (= una buena experiencia de uso)
• Métricas de servicio típicas
› Tiempo de transacción, número de transacciones por segundo
50ms
App App App
Midware Midware Midware …
SO 50 SO 50 SO
0 100 0 100
CPU CPU
Telefónica I+D 9

11. Solución
Métrica de
servicio
(pe. tiempo de
transacción) SLA 250 ms
Margen de Margen de
20%
estabilidad seguridad
Umbral de 220 ms
escalado
Escalado
Desescalado
Umbral de Margen de
estabilidad
desescalado
t
Telefónica I+D 10

12. 03
Implementación y
resultados
Telefónica I+D
Telefónica I+D 11

13. Arquitectura del sistema Clotho
OVF
RIF
Proveedor
del servicio TCloud API Usuarios del
servicio
Gestión y Gobierno
Gestor Motor de (Clotho)
de ciclo elasticidad
de vida
Acciones externas
TCloud API
Tcloud API overlay
vCenter API Monitorización VM VM VM … VM VM VM
vCenter
ESXi ESXi … ESXi
Proveedor Cloud
Telefónica I+D 12

14. Detalles
TCloud API
• Independiza del Proveedor Cloud (vCenter, RHEV, XenCenter, OpenNebula)
• Contribución al grupo CMWG de la DMTF (estandarización)
OVF como formato de descripción de servicio
• Uso de OVF para describir servicios multicapa en cloud IaaS
› DMTF, “Open Virtualization Format (OVF)”, Specification DSP0243 1.1.0, Enero 2010
› Fermín Galán, Americo Sampaio, Luis Rodero-Merino, Irit Loy, Victor Gil, Luis M.
Vaquero, Mark Wusthoff, "Service Specification in Cloud Environments Based on
Extensions to Open Standards", 4th Int’l Conf. on COMmunication System softWAre
and middlewaRE (COMSWARE 2009), Junio 2009, Dublín (Irlanda)
• Reglas de elasticidad descritas en RIF (Rule Interchange Format)
› Daniel Morán, Luis M. Vaquero, Fermín Galán, "Elastically Ruling the Cloud:
Specifying Application's Behavior in Federated Clouds", IEEE 4th Int’l Conf. on Cloud
Computing (CLOUD2011), Julio 2011, Washington DC, USA
Monitorización basada en Nagios
Motor de elasticidad basado en JBoos Drools
Telefónica I+D 13

15. Resultados
SLA
transacción de servicio (ms)
200 Applicación:
180
Escalado Umbral de escalado PetStore
Tiempo medio de
160
140
120
• GlassFish (capa
100
elástica, min=1
80 max=5)
Desescalado
60
40
• MySQL (capa
20 Umbral de desescalado inelástica)
0
14:20 14:25 14:30 14:35 14:40 14:45 14:50 14:55 15:00 15:05 15:10 15:15 15:20 15:25
• LB basado en
HAProxy conf.
(nº usuarios concurrentes)
250
por API REST
200
Sondeo por HTTP
150 GET
Carga
100
Generador de
carga JMeter
50
0
14:20 14:25 14:30 14:35 14:40 14:45 14:50 14:55 15:00 15:05 15:10 15:15 15:20 15:25
Tiempo
Telefónica I+D 14

16. 04
Conclusiones
Telefónica I+D
Telefónica I+D 15

17. Conclusiones y Líneas de trabajo futuro
Conclusiones
• La elasticidad basada en métricas de servicio protege mejor el SLA de servicio
que la basada en métricas de infraestructura
• Servicios multi-capa corporativos
• Viabilidad demostrada en el prototipo Clotho
› Usamos la tecnología referente en el mercado (48% en 2012)(*): VMware vSphere
Líneas de trabajo futuro
• Elasticidad en varias capas, detección del “cuello de botella”
• Autoconfiguración de máquinas virtuales (OVF Environment)
• LB “inteligente”
• Modularización de la arquitectura de Clotho
(*) Fuente: Gartner, “The State of Virtualization”, IT Infrastructure Operations and Management Summit, Orlando FL
(Estados Unidos), Junio 2010
Telefónica I+D 16

18. Telefónica I+D

19. Backup:
Backup: Aplicación de pruebas PetStore
Telefónica I+D 18