virtualizar o no virtualizar, esa es la cuestión | solidq summit 2012
DESCRIPTION
http://summit.solidq.com/madrid Cuando el rendimiento de nuestro servidor de base de datos está en juego, ¿compensarán los beneficios de la virtualización respecto a los inconvenientes? En esta sesión discutiremos aquellos pros y contras que conlleva virtualizar nuestros servidores SQL Server. Nos centraremos especialmente en aquellos puntos más críticos que puedan inclinar la balanza a favor o en contra de la virtualización.TRANSCRIPT
Virtualizar o no virtualizar, esa es la cuestión
RUBÉN GARRIGÓS
REL300002
Mentor – Relacional MCP – MCAD – MCSD – MCTS – MCT – MCITP
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
Optimización de infraestructura
Consumo eléctrico
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
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
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
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
Mu
ch
os
mese
s
Po
cas
sem
an
as Hazlo tu mismo DBC Appliance
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
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
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
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
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
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
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
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
Recomendaciones SQLCAT
Escalabilidad sin overcommit
Recomendaciones SQLCAT
Escalabilidad con overcommit 2:1
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
DEMO Rendimiento virtual vs físico
Duración media (ms)
0
1000
2000
3000
4000
5000
6000
Físico Virtual
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)
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
0
2000
4000
6000
8000
10000
12000
Físico Virtual Físico Virtual
1 2
Duración media y concurrencia (ms)
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
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
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
0
500
1000
1500
2000
2500
3000
Fisico Virtual
Total wait time (ms)
Total signal wait time (ms)
0
20
40
60
80
100
120
140
160
Fisico Virtual
Total wait time y concurrencia
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
Fisico Virtual Fisico Virtual
1 2
Total signal wait time por tipo (ms)
0
50
100
150
200
250
Fisico Virtual
CXPACKET
LATCH_EX
LATCH_SH
SOS_SCHEDULER_YIELD
WRITELOG
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
DEMO IOmeter
Iometer – IOPS, MBps, latencia
IOPS
0
10000
20000
30000
40000
50000
60000
Fisico Virtual Fisico Virtual
random 8KB reads sequential 2KB writes
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
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
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
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
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
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
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: