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

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?

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.

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/

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.

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).

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.

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

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.