¿Cuáles son los inconvenientes de ejecutar una base de datos dentro de una máquina virtual? ¿Cómo los supero? [cerrado]

65

Ejecutar cualquier cosa dentro de una máquina virtual tendrá cierto nivel de rendimiento, pero ¿cuánto afecta realmente el rendimiento de un sistema de base de datos?

Encontré este documento de referencia académica con algunos puntos de referencia interesantes, pero era una prueba limitada que usaba solo Xen y PostgreSQL. La conclusión fue que el uso de una VM "no tiene un alto costo en rendimiento" (aunque puede pensar que los datos reales dicen lo contrario).

¿Cuáles son los inconvenientes técnicos, administrativos y de otro tipo asociados con la ejecución de una base de datos dentro de una máquina virtual?

Publique respuestas que puedan estar respaldadas por hechos objetivos, no me interesan las especulaciones ni ningún otro argumento semirreligioso (la pasión geek es buena en muchos sentidos, pero eso no nos ayudará aquí).

Habiendo dicho eso,

  • ¿Qué problemas aparecen al ejecutar la base de datos en una máquina virtual? (por favor publique referencias)
  • ¿Son importantes esos problemas?
    • ¿Son solo significativos bajo ciertos escenarios?
  • ¿Cuáles son las soluciones alternativas?
Russ
fuente
+1 Estoy principalmente interesado en escuchar comentarios sobre los escenarios de SQL Server y Windows 2008 R2
goodguys_activate
44
@ Shane Madden - ¿Puedes explicar un poco el cierre? Espero que la motivación fue impulsada por una respuesta no específica (que luego se descarriló en los comentarios), no por la pregunta en sí. Con respecto a la pregunta, 44 votos y 12 favoritos en aproximadamente un día de existencia previa al cierre implican que fue una buena pregunta con respuestas / información útil (especialmente en comparación con lo que parece ser típico para el tráfico de preguntas de ServerFault). Esto es a lo que apuntan los diversos sitios de SE. ¿Habría preferido una formulación de preguntas más específica, frente a la floja "qué tan malo es?".
Russ
1
@ErikA, Shane, Womble, mikeyb, Ben: hice una edición de la comunidad que puede hacer que esta pregunta sea más constructiva. Considere volver a abrir esto o publicar una pregunta similar en una pregunta nueva / limpia.
goodguys_activate

Respuestas:

40

Aunque muchos proveedores de bases de datos fueron muy lentos para hacer esto, casi todos ellos ahora admiten oficialmente que su software se ejecute en un entorno virtualizado.

Ejecutamos muchas instancias de Oracle 11g en Linux sobre ESXi, y ciertamente es posible obtener un rendimiento muy bueno. Al igual que con todo el escalado de hardware, solo debe asegurarse de que el host de virtualización tenga muchos recursos (RAM, CPU) y que su capa de disco esté a la altura de la tarea de entregar cualquier rendimiento de IO que requiera.

EEAA
fuente
77
+1 Como se señaló, es crítico que los recursos estén a la altura de la tarea. El disco ha sido el gran cuello de botella para nosotros y se necesita una planificación cuidadosa.
Dave M
2
+1 Debe hacer su tarea sobre el uso de la base de datos con anticipación. Si su caja física está siendo golpeada por encima del 40% de utilización, entonces sus ventajas para verla comienzan a disolverse. Dicho esto, tenemos toneladas de pequeños sql aislados específicos de la aplicación que se ejecutan en vm sin ningún problema. Pero nuestras grandes máquinas de uso intensivo tienen hardware dedicado debido a la falta de ventaja.
Nate
55
Definitivamente, Disk IO es el gran culpable, y en qué entornos virtualizados tienden a ser escamosos.
Lynxman
1
@lynxman - De acuerdo. Ejecutamos todas nuestras instancias de Oracle en nuestros discos SAN de nivel 1, que son 15k SAS. Por lo que puedo decir, nos acercamos mucho al rendimiento casi nativo.
EEAA
10
"Vale la pena adivinar una onza de prueba".
Chris B. Behrens
21

Como dice ErikA, esto se está volviendo cada vez más común. Estoy en el campo de SQL Server y personalmente no tengo ningún sistema de producción ejecutándose en máquinas virtuales, pero no dudaría en hacerlo (después de un poco más de estudio sobre el tema). Sin embargo, definitivamente hay algunas cosas a tener en cuenta antes de seguir ese camino (al menos para SQL Server). El disco IO (como otros han mencionado) y la asignación de memoria son solo 2 ejemplos. Las cosas también serán diferentes entre diferentes hipervisores.

Brent Ozar es un reconocido experto en virtualización de SQL Server, específicamente en VMWare. Recomiendo encarecidamente leer su material.

http://www.brentozar.com/community/virtualization-best-practices/

squillman
fuente
11

Hay can y luego hay debería . Una corbeta puede ir a 150 mph, pero ¿debería usted en las carreteras públicas? Puede hacerse daño innecesariamente.

Las bases de datos son sistemas operativos invitados. Por diseño, cuando comienzan, toman bloques de un recurso y lo administran directamente por razones de rendimiento. Tan pronto como haga que el sistema operativo central del servidor de bases de datos sea un invitado en un entorno de alojamiento virtualizado, colocará una capa de arbitraje con el hipervisor entre el elemento de bloque asignado del disco y la RAM y el servidor de la base de datos. Se ralentizará. Cuanto más ineficientes sean sus consultas, más lenta será. Estas ineficiencias pueden enmascararse hoy en hardware dedicado, pero tan pronto como introduzca el arbitraje a su recurso dependiente, lo descubrirá muy rápido.

Lo que muchos contadores de beans que demandan virtualización no reconocen es que los servidores de bases de datos, como sistemas operativos invitados, ofrecen su propia capa de consolidación. No hay ninguna razón por la que no pueda mover consolidar múltiples instancias de bases de datos lógicas en un servidor físico, incluso al punto de mover direcciones IP, configurar nombres de host adicionales, etc., para permitir que esta fusión natural de servicios tenga lugar. Y, con este modelo, no solo retiene los ahorros de costos que la administración está presionando para reducir el número de hosts físicos, sino que retiene el acceso bloqueado a los recursos físicos sin la interferencia del hipervisor arbitrario, que a veces puede tomar decisiones beneficiosas y no otros.

Lo mismo se aplica a otros sistemas operativos invitados, como Java. Las soluciones de virtualización suelen ser entornos ocupados y el hipervisor tiene que tomar muchas decisiones sobre quién "obtiene el token" en un recurso. Cada vez que pueda eliminar esa capa, estará mejor.

Combine varias instancias utilizando primero la capa del sistema operativo invitado natural. Lo más probable es que pueda alcanzar los objetivos de consolidación y rendimiento de su plataforma más fácilmente.

James Pulley
fuente
44
Interesante definición de "sistema operativo invitado". Si bien su punto de vista se refiere al rendimiento puro y no adulterado, ¿con qué frecuencia sus bases de datos realmente tienen un cuello de botella en la CPU? Es mucho más probable la E / S, y para aplicaciones de mayor rendimiento ya está compartiendo el tiempo de E / S en una SAN. Espero que reconsidere su filosofía de virtualización cuando un problema de seguridad con una aplicación compromete todos los hashes de contraseña de sus bases de datos consolidadas, o cuando un proceso que se ejecuta dentro de su JVM consume cada byte de espacio de almacenamiento dinámico disponible.
Shane Madden
55
Para que quede claro, estoy completamente de acuerdo en que un servidor de base de datos de alto rendimiento finamente ajustado, masivamente ocupado, debe tener su propio hardware físico. Pero esas no son la norma, y ​​los otros beneficios de la virtualización tienden a superar el impacto en el rendimiento, que no se puede distinguir con la mayoría de las cargas de trabajo.
Shane Madden
3
No estoy de acuerdo con su punto sobre siempre ir primero a las capas de consolidación existentes. A veces eso tiene sentido. Pero observe, por ejemplo, la compensación de costos en el reequilibrio de recursos entre la consolidación de múltiples bases de datos en un solo SO y la consolidación de múltiples combinaciones de bases de datos / SO en la parte superior de un hipervisor. El primero es más eficiente. El segundo es mucho más fácil de reequilibrar. La migración y el sistema operativo / base de datos a un nuevo host es mucho menos perjudicial que la migración de una base de datos a un nuevo sistema operativo.
Jake Oshins
Mis comentarios provienen de observaciones directas en el campo de migraciones exitosas y fallidas a soluciones de virtualización durante la última década como ingeniero de rendimiento. Hay toneladas de malas aplicaciones de bases de datos cuyo uso promiscuo de hardware enmascara problemas de rendimiento. Agregue virtualización y esos problemas saldrán a la luz. Si tiene una aplicación que exige un reloj preciso para fines de temporización o auditoría, entonces con el reloj flotante en la virtualización de software, estará fuera de la caza.
James Pulley
1
Wow, solo wow James. No tengo el tiempo ni la paciencia para tirar a la basura todos los puntos que hiciste en tu respuesta y comentarios posteriores, pero sentí que necesitaba dejar un comentario aquí para cualquier persona que pudiera pasar con esta respuesta. Las opiniones de James son, bueno, propias, y no reflejan lo que es realmente posible. Si se suscribe en exceso, por supuesto , tendrá un bajo rendimiento. Así que no te des de alta. Es perfectamente posible tener un entorno de virtualización de muy alto rendimiento. Es una locura hacer una recomendación general en su contra porque "funciona mal".
EEAA
6

Hay dos cosas a tener en cuenta aquí:

  • El rendimiento de la unidad de base de datos por unidad de hardware es un poco menor para una base de datos virtualizada. Esto significa que necesita comprar un poco más de hardware para obtener el mismo nivel de rendimiento.
  • Eso no significa que no se pueda obtener el mismo nivel o el nivel deseado de rendimiento. Las ganancias que obtiene de una mejor gestión y otros beneficios (como más fácil HA) a menudo manera más que compensan los costes marginalmente el aumento de hardware.

Dicho esto, donde trabajo nuestra instalación de SQL Server es uno de los dos únicos servidores que no tengo intención de virtualizar en el corto plazo (el otro es el DC primario).

Joel Coel
fuente
4

Ejecutar SQL Server es una máquina virtual estará bien, siempre que pueda proporcionar suficientes recursos a la máquina virtual para ejecutar su aplicación. Si en el mundo físico necesita 24 núcleos y 256 Gigs de RAM, debe proporcionar 24 vCPU y 256 Gigs de RAM en el mundo virtual.

Acabo de escribir un artículo en la revista SQL Server de los últimos meses sobre cómo ejecutar SQL Server bajo vSphere de VMware.

mrdenny
fuente
2

Ejecuto dos bases de datos, una PostgreSQL y la otra MySQL, en un entorno virtual (Xen) donde los dom0s están altamente disponibles. Todos los sistemas de archivos domU están ubicados en un SAN LUN iSCSI, dividido con volúmenes lógicos LVM2. La base de datos MySQL es únicamente para Cacti, por lo que no ve mucho uso en absoluto y también se encuentra en el iSCSI LUN.

La base de datos PostgreSQL es la base de datos para nuestro entorno de ensayo y, por lo tanto, ve una mayor utilización que la base de datos MySQL. Por este motivo, la base de datos se encuentra en un conjunto RAID10 local y DRBD se replica en el segundo nodo del clúster. Sin embargo, en términos de carga real, esta base de datos provisional no ve una carga muy alta. Lo cual, en mi opinión, lo convierte en un buen / gran candidato para virtualizar.

Algunos de los beneficios para nuestra organización fueron la reducción del consumo de energía, el espacio en rack ahorrado y la menor sobrecarga administrativa de hardware.

Nuestra base de datos de producción principal, por otro lado, no puedo imaginarme virtual ...

Kendall
fuente
2

Trabajo con servidores MSSQL y MySQL en numerosos servidores. Hace un par de años, tenía mis dudas al comenzar a configurar servidores SQL en máquinas virtuales porque había escuchado sobre los problemas de rendimiento de ejecutar un servidor SQL en una máquina virtual. Sin embargo, me sorprendió después de configurar mis primeros servidores SQL y no vi ningún cambio en el rendimiento. Cada vez más servidores en los que trabajo están en VM y casi todos los clientes empresariales más grandes para los que trabajo tienen servidores SQL virtuados.

Sí, la máquina virtual agrega algunos costos generales y si va a alojar varias máquinas virtuales en una sola caja, necesitará un buen servidor robusto. Un problema de recursos común a tener en cuenta es agregar máquinas virtuales adicionales y reducir los recursos disponibles. Es una práctica común planificar un cierto crecimiento, pero si compró su servidor para alojar 2 o 3 máquinas virtuales y ahora está ejecutando 10 máquinas virtuales, probablemente verá un impacto en el rendimiento.

Mentiría si dijera que nunca he visto problemas de rendimiento al ejecutar un servidor SQL en una máquina virtual. Pero, he aprendido que si observa un bajo rendimiento, probablemente haya algo mal con el entorno.

Chris
fuente