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

CPU

Hyper-V 3.0

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

DEMO 8 vCPUs en Hyper-V 2.0

Hyper-V replica

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 Memory\Available Mbytes > 25%

\Memory\Pages/sec < 1000 *

Memoria dinámica Hyper-V Dynamic Memory Balancer/Average Pressure < 80%

Memoria guest Dependiente del tipo de máquina

Memory\Available Mbytes > 10%

\Memory\Pages/sec < 100 *

(*) Solo si Available Mbytes bajo y Paging File: % Usage significativo

Contadores de rendimiento

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

Contadores de rendimiento

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

Contadores de rendimiento

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

Best practices SQL Server

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

Best practices SQL Server

Hardware

2 vCPU por VM con 4 GB de RAM

Best practices SQL Server

Escalabilidad SQL Server con VMs pequeñas

4 vCPU por VM con 8 GB de RAM

Best practices SQL Server

Escalabilidad SQL Server con VMs medianas

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”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DEMO Impacto de los snapshots

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: