Este documento discute los objetivos y pros y contras de virtualizar SQL Server. Algunos objetivos clave de la virtualización incluyen la optimización de la infraestructura, la reducción de costos y la facilidad de mantenimiento. Entre los pros se encuentran la consolidación de servidores, la escalabilidad y la disponibilidad mejorada. Los contras incluyen un posible impacto negativo en el rendimiento, la dificultad para detectar cuellos de botella y limitaciones en algunas funcionalidades. Las pruebas muestran una merma esperable

1. Virtualizar o no virtualizar, esa es la cuestión
RUBÉN GARRIGÓS
REL300002
Mentor – Relacional
MCP – MCAD – MCSD – MCTS – MCT – MCITP
rgarrigos@solidq.com

2. Objetivos de la sesión
Objetivos virtualización
Pros de la virtualización en SQL Server
Contras de la virtualización en SQL Server
Conclusiones

3. Optimización de infraestructura

4. Consumo eléctrico

5.  Aumento del retorno de la inversión
 Disminuir los costes de operación
 Electricidad
 Refrigeración
 Espacio
 Mantenimiento
 Licencias
 Personal de IT
 Paso previo para migrar a nube de virtualización
 Más reducción de personal de IT
 Más demanda de especialistas en cloud, virtualización y negocio
Objetivos virtualización
Objetivos de negocio

6.  Facilitar las operaciones de mantenimiento
 Simplificación de la infraestructura I/O
 Red
 Almacenamiento
 Aumentar la disponibilidad
 No todas las aplicaciones/servicios disponen de alternativas como
Failover clustering, Database Mirroring, etc.
 Rapidez de aprovisionamiento de servidores
Objetivos virtualización
Objetivos técnicos

7.  Simplifica la consolidación de N instancias pequeñas en
hardware más potente
 Más flexible que otras alternativas de consolidación
 Distintas instancias y nombres
 Distintos operativos
 Distintas versiones de SQL Server
 Distintas configuraciones a nivel de servidor
 Mejor aprovechamiento del hardware
 Disponer de más capacidad para picos de IO
 Es el enfoque utilizado para la DBCA (Database
Consolidation Appliance) dentro de la propuesta de SQL
Server Private Cloud
Pros de la virtualización en SQL Server

8. DBC Appliance
Propuesta económica
Diseña la solución
Compra el hardware
Compra el software
Instala el hardware
Instala el software
Testea, valida, stress..
Ajustes de rendimiento
Comienza a consolidar
Compra el appliance
Conecta al CPD
Comienza a consolidar
Muchosmeses
Pocassemanas
Hazlo tu mismo DBC Appliance

9.  Facilita la creación de entornos de testing
 En ocasiones no podemos justificar económicamente el tener N
entornos físicos (desarrollo, integración…)
 Posibilidad de disponer de plantillas de operativo + SQL
Server para el rápido aprovisionamiento
 Sysprep + Prepare Image de SQL Server
 Solo para engine, replicación, Full-text y Reporting
 Instancias no clusterizadas
 Como mínimo siempre podremos utilizar una plantilla de
operativo + SP + instalación de SQL Server desatendida
como acelerador
Pros de la virtualización en SQL Server

10.  Permite añadir recursos extra a la máquina con un
downtime mínimo
 Podemos dimensionar a la baja y ampliar fácilmente en caso
necesario
 El clúster de virtualización tiene que tener margen
 Permite mover sistemas antiguos no soportados a
hardware nuevo
 Windows NT + SQL Server 7
 Windows 2000 + SQL Server 2000
Pros de la virtualización en SQL Server

11.  Complica detectar los cuellos de botella
 Sistemas menos predecibles
 Menos aptos para tiempo real
 El hypervisor nos limita los recursos disponibles respecto a
la máquina física  vCPUs < CPUs
 Capacidades de I/O y CPU mermadas respecto al hardware
nativo
 Throughput más reducido
 Latencias incrementadas
Contras de la virtualización de SQL Server
Rendimiento

12.  Algunos proveedores no certifican sus aplicaciones sobre
entornos virtuales
 Aunque los clúster de virtualización suelen disponer de
“pseudo HA” no sustituyen a soluciones nativas
 Clustering sobre nodos virtuales
 Requiere almacenamiento compartido virtual
 Database Mirroring sobre nodos virtuales
 Puede ser también parte de un plan ante desastres geográficos
 Grupos de disponibilidad en SQL Server 2012
 No requiere almacenamiento compartido
 Clustering por debajo
 Parte de plan de desastres
 Mejora la escalabilidad
Contras de la virtualización de SQL Server

13.  Algunas funcionalidades de los hipervisores pueden
traernos problemas
 Lock pages in memory + balloon driver
 Páginas grandes de memoria
 Limitadores de IO/CPU
 Live migration con nivel de carga medio-alto
 Normalmente son problemas técnicamente salvables
 Implica convencer a los administradores de la plataforma para que
“cambien el chip” para las virtuales con SQL Server 
 Es habitual encontrarnos con “luchas políticas” al existir conflictos de
intereses
Contras de la virtualización de SQL Server

14.  Podemos tener problemas con características que sí
tendríamos disponibles nativamente
 Drivers multipath FC
 Aceleración hardware para iSCSI
 Teaming de tarjetas de red
 Offloading de TCP/IP
 Es difícil predecir el rendimiento que tendrá nuestra
solución una vez virtualizada
 Ojo a las frecuencias de trabajo de las CPUs
 Cuidado con quienes vamos a compartirlas
Contras de la virtualización de SQL Server

15.  Podemos acabar creando “demasiadas” VMs
 1:1:1 1 SO + 1 SQL Server + 1 base de datos
 Memoria de 1 SO + 1 SQL Server infrautilizada
 Aumento del uso de CPU y de I/O
 Complicadas de mantener
 Actualizaciones SO y SQL Server
 Planes de mantenimiento
 Gestión de backups compleja
 BBDD de sistema
 Operativos
 La recomendación del SQLCAT
 No hacer overcommit de CPU  Sum(vCPU) <= Cores
 Uso intensivo de la red penalizado con más consumo de CPU
Contras de la virtualización de SQL Server

16.  Utilizar solo procesadores con ayudas a la virtualización
 Dimensionar considerando los picos de IO
 Utilizar drivers sintéticos únicamente
 Discos pass-through o VHDs fijos
 Monitorizar el host y los guests por separado
 Overcommit de CPUs físicas
 Perjudica la escalabilidad
Recomendaciones del SQLCAT

17. Recomendaciones SQLCAT
Escalabilidad sin overcommit

18. Recomendaciones SQLCAT
Escalabilidad con overcommit 2:1

19.  W2K8 R2 SP1 + SQL Server 2012 + IOmeter
 Hyper-V 2.0  W2K8 R2 SP1 + SQL Server 2012 + IOmeter
 Virtual
 4 cores y 4 GB de RAM (3 GB para SQL)
 Fichero VHD de tamaño fijo
 Físico
 8 cores (4 para SQL) y 16 GB de RAM (3 GB para SQL)
 Carga
 Select, Insert, Update y Delete
 Operaciones fila a fila y de conjuntos
 Lecturas random 8KB y escrituras secuenciales de 2KB
Demo
Entorno

20. DEMO
Rendimiento virtual vs físico

21. Duración media (ms)
0
1000
2000
3000
4000
5000
6000
Físico Virtual

22. 0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
Físico Virtual Físico Virtual Físico Virtual Físico Virtual
Delete Insert Update Select
Duración media y operación (ms)

23. Duración media y orientación (ms)
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
Físico Virtual Físico Virtual
Conjunto Fila

24. 0
2000
4000
6000
8000
10000
12000
Físico Virtual Físico Virtual
1 2
Duración media y concurrencia (ms)

25. Duración media y operación (ms)
0
2000
4000
6000
8000
10000
12000
14000
16000
Físico Virtual Físico Virtual Físico Virtual Físico Virtual
Delete Insert Update Select

26. Duración media y orientación (ms)
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
Físico Virtual Físico Virtual
Conjunto Fila

27. Duración media, orientación y concurrencia (ms)
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
1 2 1 2 1 2 1 2
Físico Virtual Físico Virtual
Conjunto Fila

28. 0
500
1000
1500
2000
2500
3000
Fisico Virtual
Total wait time (ms)

29. Total signal wait time (ms)
0
20
40
60
80
100
120
140
160
Fisico Virtual

30. Total wait time y concurrencia
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
Fisico Virtual Fisico Virtual
1 2

31. Total signal wait time por tipo (ms)
0
50
100
150
200
250
Fisico Virtual
CXPACKET
LATCH_EX
LATCH_SH
SOS_SCHEDULER_YIELD
WRITELOG

32. Total wait time por tipo excluyendo WRITELOG
0
100
200
300
400
500
600
700
800
900
1000
Fisico Virtual
CXPACKET
LOGBUFFER
PAGEIOLATCH_EX
PAGEIOLATCH_SH

33. DEMO
IOmeter

34. Iometer – IOPS, MBps, latencia

35. IOPS
0
10000
20000
30000
40000
50000
60000
Fisico Virtual Fisico Virtual
random 8KB reads sequential 2KB writes

36. Latencia (ms)
0
0,2
0,4
0,6
0,8
1
1,2
1,4
1,6
1,8
2
Fisico Virtual Fisico Virtual
random 8KB reads sequential 2KB writes

37.  El comportamiento de una carga sobre SQL Server físico
no es extrapolable linealmente a una máquina virtual
 Distinta distribución de esperas
 Distinto impacto según el tipo de operación
 Distinto impacto en función de la concurrencia
 No hay publicados tests TPC-C, TPC-E,… sobre máquinas
virtuales que nos puedan ayudar a decidir la plataforma
virtual que necesitamos
 Si no están publicados… probablemente es debido a que no arrojan
buenas cifras
 Las latencias empeoran más cuanto menores proporcionalmente
 El overhead de muchas operaciones es constante
Conclusiones

38.  Mover una instancia a una máquina virtual debe
considerarse prácticamente como si se tratara de una
migración hardware
 Dimensionamiento CPU/Memoria/IO
 Tests de rendimiento
 Throughput
 Latencia
 Tests de estabilidad
 Tests de escalabilidad
 Limites de vCPU
 Peor linealidad
 Línea base de rendimiento
 No descuidar la monitorización dentro y fuera de la VM
Conclusiones

39.  Como estimación conservadora podemos estimar:
 Throughput total: - 20%
 Latencia operaciones de escritura: + 25 %
 Latencia operaciones de lectura: + 15%
 Si migramos un servidor físico que tuviera poca carga al
pasarlo a virtual lo vamos a notar menos “snappy”, más
perezoso.
 Mayor impacto cuanto más I/O de red/disco se realice
 Las plataformas de virtualización y el soporte de
virtualización del hardware seguirá mejorando
 Fácil acabar con falsos mitos en pocos años vista
Conclusiones

40.  Host
 160 procesadores
 2 TB RAM
 63 nodos en clúster
 4000 VMs por clúster / 1024 por host
 Guest
 32 procesadores
 1 TB RAM
 64 TB disco
 NUMA virtual
En la próxima sesión…
Hyper-V 3.0

41. Conclusiones
La virtualización de SQL Server es una alternativa a las
máquinas físicas y tiene su lugar.
Evitar pedir peras al olmo
Es esperable merma de rendimiento
Debemos aprender a tomar las decisiones adecuadas
respecto a la virtualización de SQL Server en función de
nuestros escenarios
Decisiones informadas, con datos que las sustenten

42. Si quieres disfrutar de las mejores sesiones de
nuestros mentores de España y Latino América,
ésta es tu oportunidad.
http://summit.solidq.com/madrid/
Síguenos: