Hyper-V & SQL Server Best Practices
Upcoming SlideShare
Loading in...5
×
 

Hyper-V & SQL Server Best Practices

on

  • 1,497 views

http://summit.solidq.com ...

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.

Statistics

Views

Total Views
1,497
Views on SlideShare
1,496
Embed Views
1

Actions

Likes
0
Downloads
27
Comments
0

1 Embed 1

https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Hyper-V & SQL Server Best Practices Hyper-V & SQL Server Best Practices Presentation Transcript

    • 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  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
    •  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 VMspequeñas
    •  4 vCPU por VM con 8 GB de RAM Best practices SQL Server 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 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: