Hyper-V & SQL Server Best Practices

Hyper-V & SQL Server Best Practices
RUBÉN GARRIGÓS
REL300001
Mentor – Relacional
MCP – MCAD – MCSD – MCTS – MCT – MCITP
rgarrigos@solidq.com

 Arquitectura de Hyper-V 2.0 y 3.0
 Contadores de rendimiento
 Best Practices para SQL Server sobre Hyper-V
Contenido

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

 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

 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

 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

 Mayor escalabilidad
 Menos limitaciones
 Más VMs por host
 Y aun pueden mejorarse en la RTM…
CPU
Hyper-V 3.0

 Activar NUMA spanning en el host como última opción
 VM UMA
 Más riesgo de penalizaciones por acceso a memoria
remota
Memoria
Hyper-V 2.0

 NUMA spanning activado por defecto
 VM  vNUMA
 Mejor escalabilidad para cargas NUMA-aware como las de
SQL Server
Memoria
Hyper-V 3.0

 Hasta 1 TB en una máquina virtual
 Memoria por nodo vNUMA configurable
Memoria
Hyper-V 3.0

Comparativa
CPU, memoria y disco
XenServer 6.0 Hyper-V 2.0 Hyper-V 3.0 vSphere 5.0
Cores en Host 160 64 160 160
RAM en Host 1TB 1TB 2TB 2TB
vCPUs por VM 16 4 32 32
RAM por VM 128GB 512GB 1TB 1TB
Disco 2TB 2TB 64TB 2TB
Nodos cluster 16 16 63 32
Total VMs ~1200 1000 4000 3000

 SR-IOV  Virtualización hardware de la tarjeta
 1 dispositivo PCIe aparece como múltiples dispositivos
Network
Hyper-V 3.0

 Protección ante servidores DHCP y enrutadores
Network
Hyper-V 3.0

 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

 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

 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

 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

 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

 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

 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

 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
Memoria

 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
Disco

 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
Network

 Utilizar hardware con baja latencia para virtualización y
soporte de SLAT (EPT, RVI)
Best practices SQL Server
Hardware

 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
Hardware

 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
Hardware

 2 vCPU por VM con 4 GB de RAM
Escalabilidad SQL Server con VMspequeñas

 4 vCPU por VM con 8 GB de RAM
Escalabilidad SQL Server con VMsmedianas

 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
Memoria “estática”

 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
Memoria dinámica

 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
Memoria dinámica

 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
Memoria dinámica

 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
Memoria dinámica

 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
Memoria dinámica

 En Hyper-V 3.0 podemos evitar los ficheros .BIN si
elegimos apagar la máquina por defecto
Memoria dinámica

 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é
Lock pages in memory

 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
Memoria vs IO
IOPS
Memoria
Throughput

 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
Memoria vs IO

 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
Memoria dinámica

 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
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

 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
Memoria dinámica

 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
Disco

 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
Disco

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:

Hyper-V & SQL Server Best Practices

Recommended

Recommended

More Related Content

More from SolidQ

More from SolidQ (20)

Hyper-V & SQL Server Best Practices