I remember the old days, when I wasn’t a fan of Installing SQL Server on Virtual Machines, but in todays world thanks to Hyper-V 2012 (and I guess VMWARE too), a lot of the resource bottlenecks for virtual machines has disappear. However still it’s not for every workload.

Recently I was on one of my clients that has a kind of big Virtual Shop on Hyper-V 2012R2, and he ask me. Well I’m planning the Installation of Multiple SQL Server for some management applications on a few VMs, how should I provide the High Availability for this?

That was a good question, we had many options, but we rapidly decided to have some kind of a Cluster, now we had two options, Clustering the Hyper-V Virtual Machines or doing a SQL Guest Failover Cluster between Virtual Machines.  

The first one is a good option to mitigate downtime when the hardware failed, if one of the Hyper-V Virtual Machines Node failed, the Virtual Machines will just failover to another node, but what would happen just when the SQL Services failed? It wouldn’t trigger a failover, at least not by default, I guess we could create some kind of script to monitor the SQL Services and then trigger a VM Failover, but It doesn’t sound right. Now in the other hand we have Live Migration on this configuration, that allows us to move virtual machines with 0 downtime.

The second one is a great option, and have all the usual benefits of a SQL Server Failover Cluster, just use the 2 Virtual Machines, and create a SQL Cluster between this 2, this is called a SQL Guest Failover Cluster.

One of the question was could I combine the 2 options, and yes you could, but take into consideration the following:

• Your could Use a lot more resources than necessary
• In a physical failure you could lose your High Availability

Why? Lets suppose this scenario, We have 2 physical nodes were we create a Windows Cluster, and we configure 2 VMs as resources on this Windows Cluster (The First Option), you configure one VM to run in node1 and the other VM to run in node2, now you create a SQL Guest Failover Cluster between the to VMs (The Second Option). What will happen when Node1 crash (ex: Mother Board Failure), the 2 VMs will be running on Node2 consuming a lot of resources, and you will also not have real High Availability as your workload is running only in one physical server.

In conclusion, should I combine the two options, depend on you resource availability, and also how critical is the workload you are running against SQL. However what you should ALWAYS do is follow the best practices for configuring SQL on a Hyper-V environment.

Running SQL Server 2008 in Hyper-V Environment 

Running SQL Server with Hyper-V Dynamic Memory - Best Practices and Considerations

Consolidating Databases Using Virtualization Planning Guide

Hope you like the post, you can follow me on twitter @SQLDixitox and on facebook https://www.facebook.com/SQLbyEdinsonMedina 

Recuerdo los viejos días cuando no era un fanático de colocar a SQL Server en Máquinas Virtuales, pero hoy en día gracias a Hyper-V 2012 (y VMWARE), muchos de los cuellos de botella en recursos que existían en las máquinas virtuales han desparecido. Sin embargo aunque ha mejorado en gran medida no es para todas las cargas de trabajo.

Recientemente estaba en uno de mis clientes que tiene un Virtual Shop en Hyper-V 2012, y me pregunto: Estoy planificando la instalación de múltiples Instancias de SQL Server para algunas aplicaciones de administración en máquinas virtuales, como debo proveer la Alta Disponibilidad?

Esto es una Buena pregunta, tenemos varias opciones, pero rápidamente decidimos usar alguna forma de Cluster, entonces tenemos solo 2 opciones, Clusterizar la Máquinas Virtuales de Hyper-V o hacer un Guest Failover Cluster de SQL Server entre las máquinas virtuales.

La primera opciones es Buena para mitigar el downtime cuando el hardware falla, si uno de los Nodos de las Máquinas Virtuales de Hyper-V, las máquinas virtuales simplemente harán un failover a otro nodo, pero que pasaría cuando solo falle el servicio de SQL? Esto no iniciaría un failover, por lo menos no por defecto, supongo que se puede crear algún tipo de script que monitorea el servicio de SQL y luego disparar una falla a nivel de la VM, pero no suena muy adecuado. . Ahora por el otro lado, en esta configuracion tenemos Live Migration que nos permite mover maquinas virtuales con 0 downtime.

La segunda opción, es una excelente, y tiene todos los beneficios de SQL Server Failover Cluster, simplemente se usan las 2 máquinas virtuales, y se crea un SQL Cluster entre las mismas, esto es llamado un SQL Guest Failover Cluster.

Una de las preguntas fue, puedo combinar las 2 opciones? y Si se podría, pero tengan en consideración lo siguiente:

• Puede que usen muchos más recursos de los necesarios
• En caso de la falla de un servidor físico, podrían perder la Alta Disponibilidad

Porque? Supongamos un escenario, Tenemos 2 nodos físicos donde creamos un Windows Cluster, y luego configuramos 2 Máquinas Virtuales como recursos del Windows Cluster (La primera opción), se configure que una de las máquinas virtuales se ejecute sobre el nodo1 y la otra máquina virtual se ejecute en la nodo2, ahora se crea un SQL Guest Failover Cluster entre las máquinas virtuales (La segunda opción). Que pasaría cuando el nodo1 falle (ejm: Falla de la tarjeta madre), las 2 máquinas virtuales se ejecutaran en el nodo2 consumiendo una gran cantidad de recursos, y adicionalmente no tendrán verdadera alta disponibilidad ya que tu carga de trabajo esta ejecutándose en un único servidor físico.

En conclusión, debería combinar las opciones?, depende en la disponibilidad de recursos que tengas, también que tan crítica es la carga de trabajo que ejecutas contra SQL Server. Sin embargo, lo que SIEMPRE debes hacer es usar las mejores prácticas de configuración para SQL Server en un ambiente Hyper-V.

Running SQL Server 2008 in Hyper-V Environment

Running SQL Server with Hyper-V Dynamic Memory - Best Practices and Considerations

Consolidating Databases Using Virtualization Planning Guide

Espero que les haya gustado el contenido, me pueden seguir en twitter @SQLDixitox y en facebook https://www.facebook.com/SQLbyEdinsonMedina

Duración: 30 min.  

Tema: SQL Server Sysprep. 

Descripción del tema: En este tea tocaremos los pasos que debemos seguir para crear una imagen de SQL Server y Windows Server. 

Objetivo: Dar a conocer cómo funcionan la caracteristica de sysprep en SQL Server y como la podemos usar para automatizar a creacion de maquinas con una Instancia de SQL Server.  

Presentador: Edinson Medina

Idioma: Ingles