http://summit.solidq.com
Si debemos administrar instancias de SQL Server ya virtualizadas con Hyper-V deberemos tener en cuenta que no podemos ser agnósticos respecto a la virtualización. Una configuración de memoria apropiada para una máquina física no será siempre la óptima en un entorno virtual. Un grado máximo de paralelismo adecuado para una máquina física puede darnos también sorpresas desagradables en entornos virtuales. La virtualización ha llegado para quedarse así que aprendamos cómo configurar adecuadamente nuestros SQL Server en dichos entornos.
2. Arquitectura de Hyper-V 2.0 y 3.0
Contadores de rendimiento
Best Practices para SQL Server sobre Hyper-V
Contenido
3. Arquitectura Hyper-V
Windows Server
2008
VSP
Windows
Kernel
Applications Applications Applications
Non-
Hypervisor
Aware OS
Windows Server
2003, 2008
Windows
Kernel VSC
VMBus Emulation
“Designed for Windows” Server Hardware
Microkernel - Windows hypervisor
Xen-Enabled
Linux Kernel
Linux
VSC
Hypercall Adapter
VM Service
WMI Provider
VM
Worker
Processes
User
Mode
Kernel
Mode
Ring -1
IHV
Drivers
VMBus
VMBus
4. Hypervisor monolítico
Más código en modo
privilegiado
No hay partición padre
Todas las VMs al mismo
nivel
Evolución más lenta en
funcionalidades por el
riesgo de afectar a la
estabilidad del hypervisor
Virtualización con otros proveedores
Scheduler
Memory Management
Storage Stack
Network Stack
VM State Machine
Virtualized Devices
Drivers
Management API
Hardware
User
Mode
Kernel
Mode
User
Mode
Kernel
Mode
User
Mode
Kernel
Mode
5. Windows Server 2012 2012 Q4
Grandes mejoras
Escalabilidad y NUMA
Más máquinas virtuales, más vCPUs, más nodos, más memoria…
Live migration y Storage Live Migration
Migraciones de VMs entre clusters
VHDX hasta 16TB por disco
ODX Offloaded Data Transfer
Hyper-V replica
DR low-cost
Muchas más mejoras
Ligadas a Windows Server 2012: SMB 3.0, Scale-out fileservers,
Teaming de red heterogéneo, Windows Update “cluster-aware”,
clusters de 63 nodos
Hyper-V 3.0
6. Hyper-V 2.0
Windows Server 2008 / Windows 7 1 a 4 vCPUs
Windows Server 2003 /Windows XP 1 a 2 vCPUs
Windows 2000 1 vCPU
Linux 1 a 4 vCPUs
Hyper-V 3.0
De 1 a 32 vCPUs
El máximo soportado dependerá del SO
Windows 2008 R2 / Windows 8 / Windows Server 2012 hasta 32
vCPUs
CPU
Limitaciones de VCPUs
7. Mayor escalabilidad
Menos limitaciones
Más VMs por host
Y aun pueden mejorarse en la RTM…
CPU
Hyper-V 3.0
16. Se ha eliminado el soporte de TCP Chimney en las VMs
VLAN obsoletas para VMs (con excepciones)
1000 VLANs máximo
No cubrían múltiples subredes
Dependían de una red física
El aislamiento de redes se realiza a nivel de host de Hyper-V
Permite mover cualquier máquina a cualquier servidor del
datacenter
Permite configurar mínimos y máximos de ancho de banda
Network
Hyper-V 3.0
17. Nueva controladora Fiber Channel
Boot desde fiber channel y iSCSI SAN
Soporte nativo de discos 4K
Offload Data Transfer (ODX)
Merge de snapshots en caliente
Disk
Hyper-V 3.0
20. Necesitaríamos una sesión solo para tratar Hyper-V réplica
en profundidad
Comunicación por http
Replicas ilimitadas incluidas
Entre cluster y no-cluster
Hasta 15 puntos de recuperación
Restores cada 5 minutos y alertas tras 30 minutos
Podemos perder entre 1 segundo y 1 hora del negocio
Replica health check
Replica test failover
Siempre debemos testear nuestra estrategia de DR
Hyper-V replica
Características clave
21. Primero las más críticas
Reducimos el tiempo de
no disponibilidad
Las de mayor memoria
mínima
Reducimos la
fragmentación de memoria
En caso de clusters
virtuales podemos dejar
el nodo pasivo apagado
Hyper-V 3.0
Prioridades de arranque
22. Hyper V 2.0
http://download.microsoft.com/download/C/A/9/CA9292AD-3A33-
4984-A9CF-82B08FCEFE77/WindowsServer2008R2Hyper-
VComponentArchitecture.pdf
Hyper-V 3.0
http://download.microsoft.com/download/F/6/9/F6932D74-4ADD-
4366-B2BE-
22CE4D94E54F/Windows%20Server%20“8”%20Beta%20Hyper-
V%20Component%20Architecture%20Poster.pdf
Poster de los componentes
23. Host (partición padre)
Guest (partición hijo)
Muchísima información disponible
CPU, Memoria, Disco, Red, Interrupciones, operaciones gestión,
Vmbus, estado de las máquinas, etc.
Si tenemos muchas máquinas virtuales..
System Center VMM ~ V-Center + P2V
DW con datos de monitorización + Reporting Services
Contadores de rendimiento
Introducción
24. Total Hyper-V Hypervisor Logical Processor
Hypervisor % Hypervisor Run Time
Host Hyper-V Hypervisor Root Virtual Processor
Guests Hyper-V Hypervisor Virtual Processor
Idealmente no pasar del 60% de CPU de media para un
buen rendimiento y tener algo de margen para picos
Analizar dónde está el mayor consumo por si algún
driver/aplicación/servicio tiene problemas con Hyper-V
Intel Westmere/Sandy Bridge
Windows Server R2 SP1 + KB2517329
Contadores rendimiento
CPU
25. Memoria host
MemoryAvailable Mbytes > 25%
MemoryPages/sec < 1000 *
Memoria dinámica Hyper-V Dynamic Memory Balancer/Average
Pressure < 80%
Memoria guest
Dependiente del tipo de máquina
MemoryAvailable Mbytes > 10%
MemoryPages/sec < 100 *
(*) Solo si Available Mbytes bajo y Paging File: % Usage significativo
Contadores de rendimiento
Memoria
26. Dependiendo de la configuración debemos monitorizar a
nivel de guest o de host
iSCSI / FC directo guest
Disco pass-through guest
VHDs sobre discos locales guest + host
VHDs sobre CSV guest + host
Host y guest
Logical Disk(*)Avg. sec/Read
Logical Disk(*)Avg. sec/Write
Las mediciones en guest son más precisas y a nivel de host
muestran valores agregados
Contadores de rendimiento
Disco
27. Tiempos esperados de copia de un fichero
100 MB sobre 100Mbit < 15 segundos
100 MB sobre 1000Mbit < 4 segundos
Host
Network Interface(*)Bytes Total/sec < 50%
Network Interface(*)Output Queue Length < 2
Hyper-V Virtual Network Adapter(*)Bytes/sec
Desactivar TCP offload/chimney/RSS en el host y en el
guest si detectamos pérdidas de conexiones o
inestabilidad en la red
Especialmente con tarjetas Broadcom
Fijar la velocidad de la red, no usar la autodetección
Contadores de rendimiento
Network
28. Utilizar hardware con baja latencia para virtualización y
soporte de SLAT (EPT, RVI)
Best practices SQL Server
Hardware
29. Procesadores con caché L3 grande
Baja latencia para acceso a memoria remota
Especialmente si usamos NUMA spanning
Preferible una frecuencia de proceso alta vs muchos cores
Best practices SQL Server
Hardware
30. Es muy importante realizar las pruebas de concepto con
hardware similar al de producción
Comenzar con un cluster de 1 nodo y ampliarlo
En ocasiones hemos visto escenarios donde el hardware virtual es
un “downgrade” sobre el actual físico
Punto de entrada recomendado 125%
CPU
Memoria
IO
Cores 25% más rápidos
Bien en rendimiento por ciclo o en frecuencia
No es suficiente con tener más cores
Best practices SQL Server
Hardware
31. 2 vCPU por VM con 4 GB de RAM
Best practices SQL Server
Escalabilidad SQL Server con VMspequeñas
32. 4 vCPU por VM con 8 GB de RAM
Best practices SQL Server
Escalabilidad SQL Server con VMsmedianas
33. Dimensionamiento similar al que realizaríamos en una
máquina física
Más estabilidad y predictibilidad
Permite el uso de vNUMA
Al contrario que la CPU, la memoria no es un recurso que
pueda compartirse, solo particionarse
Típicamente + memoria = - IO a disco
Mejorar la IO a disco es costoso y complejo
Cada vez las CPUs son más potentes por lo que necesitamos un
ratio de más GB de RAM por core para consolidar eficientemente
Best practices SQL Server
Memoria “estática”
34. Startup Memory
Minimum memory Hyper-V 3.0 en el GUI
Puede ser inferior a la startup memory
Maximum memory
Se puede aumentar en caliente
Memory Demand Committed memory VM
Memory Buffer Porcentaje sobre la demanda
Deshabilita vNUMA
Necesita SQL Server EE/Datacenter hasta 2008 R2
SQL Server 2012 standard soporta Hot-Add Memory
cuando está virtualizado
Best practices SQL Server
Memoria dinámica
35. Añadir memoria Enlightened Memory Addition
Reducir memoria Memory Ballooning
Calcular la memoria libre para el host de Hyper-V
384 MB + 30 MB por GB en VMs
Servidor con 48 GB en virtuales ~1.8 GB
1 GB minimo para el SO
X GB para otros procesos en el host
Antivirus, herramientas backup, servicios, etc.
Para un servidor con 64GB de RAM, en un cluster de 3 nodos, 48GB en
virtuales, 4 GB para el SO + Hyper-V + antivirus y 12GB para failovers
Best practices SQL Server
Memoria dinámica
36. Nos permite un mejor aprovechamiento de los recursos
del cluster de virtualización
Maximizar la memoria en uso por las máquinas virtuales
Reducir el riesgo de falta de memoria en caso de failover
No fijar mínimos de memoria muy altos
Mejora del rendimiento al reducirse la IO a disco,
especialmente en aplicaciones intensivas en memoria
como SQL Server
Best practices SQL Server
Memoria dinámica
37. Hyper-V no pagina la memoria de las VMs en el fichero de
paginación del host
Fichero .BIN para mapear la memoria de cada VM en caso necesario
No es overcommit de la memoria del host
Aumenta la importancia del fichero de paginación de la
VM
En un servidor SQL Server típico no tiene casi uso y suele ubicarse
en C: sin demasiado cuidado
Con memoria dinámica es necesario pasar por él antes de asignar
nueva memoria física dinámicamente por lo que debe estar bien
dimensionado
Puede ser interesante situarlo en un disco independiente
Hyper-V replica
Best practices SQL Server
Memoria dinámica
38. Smart Paging Buffer de memoria virtual temporal
Configurable por cada máquina virtual
Útil en un reinicio donde el consumo de RAM de muchas
VMs estaba por debajo del configurado en el arranque
Best practices SQL Server
Memoria dinámica
39. En Hyper-V 3.0 podemos evitar los ficheros .BIN si
elegimos apagar la máquina por defecto
Best practices SQL Server
Memoria dinámica
40. Configuración recomendada con memoria dinámica
Habilitar lock pages in memory
Limitar el consumo máximo de la instancia por debajo del
total
Misma recomendación que con memoria estática
Conseguimos reducir la caída de rendimiento cuando
necesitamos inflar el balón de memoria
No paginamos el buffer caché
Best practices SQL Server
Lock pages in memory
41. Especialmente relevante si tenemos memoria dinámica
pero aplica en general
Similar comportamiento al que tendríamos con una
máquina física pero “radicalizado” por la competencia
entre VMs
Best practices SQL Server
Memoria vs IO
IOPS
Memoria
Throughput
42. Con memoria dinámica, en caso de failover, debemos
esperar un aumento en la IO muy superior a la habitual.
Pruebas de escalabilidad
¿IOPS x2 latencia x10?
¿R/W 80/20 = R/W 20/80?
Pruebas de stress con carga real
Riesgo de perder la HA efectiva
El servidor va tan lento que da timeout
Los usuarios se quejan de que no pueden trabajar
Estamos perdiendo ventas
Best practices SQL Server
Memoria vs IO
43. Monitorización desde Hyper-V Manager
Assigned Memory Memoria física asignada
The Memory Demand Committed memory en la VM
Memory Status Estado del buffer
OK Tenemos suficiente memoria
Low Necesitamos más memoria física o reconfigurar VMs
Warning El rendimiento puede estar ya muy degradado
Best practices SQL Server
Memoria dinámica
44. Solo en SQL Server EE/Datacenter hasta 2008 R2
Preferiblemente VM “monoinstancia”
Combinar con lock pages in memory
No utilizar large page memory
Lo proporciona Hyper-V y no permite cambiar la memoria en uso
Para instancias pequeñas que no se beneficien de NUMA
Best practices SQL Server
Memoria dinámica
Startup RAM 1 GB + SQL Min Server Memory
Maximum RAM > SQL Max Server Memory
Memory Buffer % 5
Memory Weight Depende de la prioridad
45. Whitepaper de MS sobre memoria dinámica y SQL Server
http://msdn.microsoft.com/en-us/library/hh372970.aspx
Whitepaper de memoria dinámica de Aidan Finn
http://www.aidanfinn.com/?download=Dynamic Memory
Whitepaper
Blog del SQLOS team
http://blogs.msdn.com/b/sqlosteam/archive/2011/01/31/sql-server-
and-hyper-v-dynamic-memory-part-1.aspx
Blog del Virtualization team
http://blogs.technet.com/b/virtualization/archive/2010/03/18/dyna
mic-memory-coming-to-hyper-v.aspx
Configuración y monitorización de la memoria dinámica
http://technet.microsoft.com/en-us/library/ff817651(v=ws.10).aspx
Best practices SQL Server
Memoria dinámica
46. Antes de desplegar las máquinas virtuales comprobar las
diferencias de rendimiento con SQLIO / IOmeter
De mayor a menor rendimiento
FC en Hyper-V 3.0
Discos pass-through, FC, DAS, iSCSI acelerado por HW
VHD de tamaño fijo
iSCSI software directo a guest
VHD dinámicos (a evitar…)
Instalar siempre los Hyper-V Integration Services
Minimizar los snapshots
Best practices SQL Server
Disco
47. Dimensionamiento en IOPS efectivas
Tener en cuenta el overhead de la configuración elegida
Considerar que si tenemos presión de memoria nos
acabará generando más IO
Dimensionar para el peor escenario al que queramos dar soporte
2 nodos 1 down, 3 nodos 1-2 down?
Separar la IO de los entornos de desarrollo, preproducción
y producción
Optimizar la IO en función de su naturaleza
Logs
Datos
Tempdb
Best practices SQL Server
Disco
49. 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: