Virtualizar o no virtualizar, esa es la cuestión | SolidQ Summit 2012
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Virtualizar o no virtualizar, esa es la cuestión | SolidQ Summit 2012

on

  • 869 views

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

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.

Statistics

Views

Total Views
869
Views on SlideShare
866
Embed Views
3

Actions

Likes
1
Downloads
8
Comments
0

2 Embeds 3

http://www.linkedin.com 2
http://www.kred.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

Virtualizar o no virtualizar, esa es la cuestión | SolidQ Summit 2012 Presentation Transcript

  • 1. Virtualizar o no virtualizar, esa es la cuestión RUBÉN GARRIGÓS REL300002 Mentor – Relacional MCP – MCAD – MCSD – MCTS – MCT – MCITP rgarrigos@solidq.com
  • 2. 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
  • 3. Optimización de infraestructura
  • 4. Consumo eléctrico
  • 5.  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
  • 6.  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
  • 7.  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
  • 8. 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 Muchosmeses Pocassemanas Hazlo tu mismo DBC Appliance
  • 9.  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
  • 10.  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
  • 11.  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
  • 12.  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
  • 13.  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
  • 14.  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
  • 15.  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
  • 16.  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
  • 17. Recomendaciones SQLCAT Escalabilidad sin overcommit
  • 18. Recomendaciones SQLCAT Escalabilidad con overcommit 2:1
  • 19.  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
  • 20. DEMO Rendimiento virtual vs físico
  • 21. Duración media (ms) 0 1000 2000 3000 4000 5000 6000 Físico Virtual
  • 22. 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)
  • 23. 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
  • 24. 0 2000 4000 6000 8000 10000 12000 Físico Virtual Físico Virtual 1 2 Duración media y concurrencia (ms)
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. 0 500 1000 1500 2000 2500 3000 Fisico Virtual Total wait time (ms)
  • 29. Total signal wait time (ms) 0 20 40 60 80 100 120 140 160 Fisico Virtual
  • 30. Total wait time y concurrencia 0 10000 20000 30000 40000 50000 60000 70000 80000 90000 Fisico Virtual Fisico Virtual 1 2
  • 31. Total signal wait time por tipo (ms) 0 50 100 150 200 250 Fisico Virtual CXPACKET LATCH_EX LATCH_SH SOS_SCHEDULER_YIELD WRITELOG
  • 32. 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
  • 33. DEMO IOmeter
  • 34. Iometer – IOPS, MBps, latencia
  • 35. IOPS 0 10000 20000 30000 40000 50000 60000 Fisico Virtual Fisico Virtual random 8KB reads sequential 2KB writes
  • 36. 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
  • 37.  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
  • 38.  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
  • 39.  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
  • 40.  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
  • 41. 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
  • 42. 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: