Consulta Técnica: Bases de datos en entornos virtualizados.

Mi tocayo José Luis, viejo conocido de esta casa, nos pregunta:

"José Luis:

Te queríamos hacer una pregunta. No sé si a lo mejor podría ser interesante que apareciera en el blog. Está relacionada con la virtualización de BBDD.

En nuestro entorno el grueso de las BBDD lo conforman sqlserver, mysql y sybase. En los primeros tiempos de nuestra “vida virtual”, con servidores poco potentes y en fase de aprendizaje, hicimos algunas pruebas virtualizando algunas bbdd mysql. Los resultados no fueron demasiado buenos y prácticamente se descartó desde el principio en entornos sybase y sqlserver. En mysql seguimos probando pero estamos dejando solamente las muy pequeñas y con muy poca carga, porque nos hemos encontrado con cuelgues inexplicables, siempre con Linux, por ejemplo al descomprimir o hacer vi en un fichero. Tampoco hablamos de BBDD muy grandes, nunca mayores de 40 Gb.

Nos gustaría conocer vuestra experiencia en este mundo hasta ahora vedado para nosotros.

Muchas gracias
José luis"

La de las bases de datos es una vieja guerra entre los DBA y nosotros los forofos de la virtualización. Por un lado, y con toda la razón, nuestros DBA ven en la virtualización una limitación de potencia para las siempre hambrientas de potencia y memoria bases de datos. Por otro, los chicos malos de sistemas, vemos que la virtualización puede aportar ventajas extraordinarias a un sistema tan crítico como las bases de datos. Voy a contaros mi experiencia en un caso en particular.

Cierta empresa del grupo empezó a reportar problemas de rendimiento con su flamante SQL server. Esta empresa tiene a unos 700 operadores conectados permanentemente a una aplicación .NET que se alimenta de una serie de bases de datos, que también resultan "machacadas" en segundo plano por un cubo OLAP. Vamos, un destroza-máquinas. La primera intención, hace ya dos años, fué cambiar el hardware por otro más potente... y se hizo, lo que supuso retrasar unos meses más el problema. Posteriores investigaciones descubrieron una serie de estupendas queries dignas de cualquier stress-test de base de datos. Hace unos meses, decidimos virtualizarlas, dedicando un ESX completo a esta base de datos. La pregunta que se os vendrá a todos a la cabeza es "¿Porqué no lo dejaste en físico?, porque no le veo demasiado sentido a utilizar un sólo ESX a una sola VM" La respuesta es que me decidí a encapsular (y fijaos que no digo virtualizar) la VM para poder moverla a máquinas más potentes según fuese ampliando mi infraestructura virtual. Encapsular la máquina no mejoró los tiempos de la base de datos (Hay un post al respecto en este blog: La virtualización no arregla los problemas de rendimiento), pero me permite asígnar más recursos a esta VM en caliente.

Encapsular esta base de datos también me permite realizar copias consistentes de la máquina cada 6 horas, algo impensable en el entorno físico, ya que la ventana de intervención diaria en esta base de datos es inferior a dos horas entre semana, e inferior a 12 en fines de semana. En la actualidad, y ante un desastre, somos capaces de levantar la VM en otra ubicación en menos de una hora, lo que resultaba, como digo, impensable hace unos meses.

La capacidad de snapshotting de VMware, junto con la del NetApp 3020 donde almaceno los datos, me permite, por primera vez, pasos a producción de nuevas versiones (que constantemente requieren de modificaciones en la estructura de la base de datos) con total garantía de marcha atrás, llevando los tiempos máximos de retorno (ese periodo máximo de tiempo que tenemos para volver atrás en caso de que se agote la ventana de paso a producción), a escasos minutos antes de que se me acabe la ventana.

Cuando se nos plantea, como es el caso, redundar geográficamente la base de datos, y la publicación/subscripción no es una opción dado el impacto de rendimiento que tiene en la base de datos, la encapsulación, combinada con la tecnología de snapshotting de mi NetApp 3020, me permite redundar completamente el servidor entre dos CPD sin preocuparme de aplicar doblemente los cambios en base de datos, configuración del servidor y demás. De hecho, y tras las pruebas preliminares, estamos planteando replicar la VM entera cada... ¡¡¡ hora !!!

En resumen: Los números hablan. Tras casi 50 pasos a producción en los últimos dos meses, ni uno ha excedido la ventana. Ningún efecto colateral de las "marchas atrás" ha afectado a la producción, y el efecto de la virtualización no ha supuesto impacto apreciable en el rendimiento de la aplicación.

Espero haberte sido de ayuda.

Un saludo.