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

En Junio y Octubre 2013 estuve apoyando a dos clientes en la actualización de sus plataformas productivas de Project Server 2010. Dado que en ambos casos no se disponía de procesos formales para actualizar de SharePoint 2010 o Project Server 2010, las actualizaciones se aplicaron en Producción:

• Cliente 1 requirió aplicar el paquete de actualizaciones acumulativas de Abril 2013 para su Plataforma Project Server 2010 SP 1 en inglés (con paquetes de lenguaje en español). 

  • El error: la página “Centro de Proyectos” no cargaba, se mantenía en el mensaje “Cargando”.

  • La revisión arrojó que la actualización no reconocía la zona horaria “-04:30 GMT” (Venezuela) que utilizaba la colección de sitios “PWA”.

  • La solución: luego de aplicar el Service Pack 2 en un ambiente de pruebas, la página “Centro de Proyecto” volvió a mostrarse satisfactoriamente, al establecer la zona horaria “-04:30 GMT”.

     

• Cliente 2 requirió aplicar el Service Pack 2 para su Plataforma Project Server 2010 SP 1 en español

  • El error: la página “Centro de Proyectos” tampoco se mostraba, como ocurrió en el ambiente del cliente 1.

  • La revisión arrojó que la actualización a Service Pack 2 no reconoce la zona horaria “-04:30 GMT”.

  • La solución no he encontrado hasta este momento una actualización acumulada que solvente este error. Tan pronto conozca de la actualización que lo corrija, estaré refrescando esta publicación.

Mientras tanto, es importante recordar que Microsoft publica actualizaciones (parches) para todos sus productos, con el objeto de mejorar su funcionalidad en el transcurso del ciclo de vida de cada versión de los mismos. Microsoft publica cada  actualización periódicamente (como un Service Pack o Actualización Acumulada) o de acuerdo a los errores descubiertos en el tiempo (como hotfixes). Para los productos y tecnologías SharePoint 2010, se debe considerar la actualización de todos sus componentes internos (Sistema Operativo, Base de Datos, Pre requisitos de SharePoint a nivel fundacional, Servidor y paquetes de lenguaje) y complementarios (Project Server, SQL Server Reporting Services en modo integrado con SharePoint, FAST entre otros).

Al aplicar actualizaciones a SharePoint 2010, considere:

• Definir, implementar y mantener actualizada la estrategia de actualización, de acuerdo a las políticas de TI, Seguridad, continuidad de negocios de su organización.

• Microsoft recomienda:

  • Mantener las tecnologías y Productos SharePoint 2010 actualizados al menos con el Service Pack más reciente.

  • Aplicar actualizaciones acumuladas (CU por sus siglas en Inglés) solo cuando su Plataforma presente algún problema que sea solventado por el CU.

  • Revisar las secciones “Resumen” y “Resolución” de los artículos que describen los CU’s que usted prevé aplicar:

    • Resumen: describe la actualización y en algunos casos, los problemas que se pueden presentar luego de aplicar la actualización, así como pueden ser solventados.

    • Resolución:  resume los problemas que se corrigen, los pre requisitos para la instalación, reinicio y archivo de información.

Artículos recomendados:

 Software updates overview (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/ff806329(v=office.14).aspx

 Updates for SharePoint 2010 Products (http://technet.microsoft.com/en-us/sharepoint/ff800847.aspx )

 Deploy Project Server 2010 updates (http://technet.microsoft.com/en-us/library/gg598486(v=office.14).aspx  )

During June and October 2013, I was supporting two customers in Venezuela, in order to update their SharePoint 2010 and Project Server 2010 production environments. Customers did not have testing environments, neither a formal patch management strategy, therefore, they decided update directly in Production:

• Customer 1 required apply Cumulative Update April 2013 for its SharePoint 2010 SP1 and Project Server 2010 SP1 English environment (with Language Pack for Spanish)

The error: “Project Center” page, of PWA site only show the message “loading” and did not display the Project center info.

The troubleshooting raised that these updates does not consider time zones with a half hour, like “-04:30 GMT” Venezuela’s time zone.

The workaround was change the time zone of the PWA’s site collection. Customer needs to consider the impact of this change for its contents, workflows and any customization that use the time zone. Microsoft Support has delivered a private Hot Fix for the environment of this customer.

The solution was found by applying SharePoint Server 2010 and Project Server Service Pack 2 in a QA environment, the “Project Center” page was rendered successfully, using the “-04:30 GMT” Venezuela’s time zone.

• Customer 2 required apply Service Pack 2 for its SharePoint Server 2010 SP1 and Project Server 2010 SP1 Spanish environment.

The error: It was the same like Cutomer 1: “Project Center” page, of PWA site only show the message “loading” and did not display the Project center info.

The troubleshooting raised a similiar situation like Cutomer 1. The Service Pack 2 (Spanish) does not consider time zones with a half hour, like “-04:30 GMT” Venezuela’s time zone.

The workaround set the "PWA" site collection's time zone  to a value different to “-04:30 GMT” (or any time zone with 30 minutes).

The solution I don't found a solution at this momento. I will be updating this post as soon I find a Cumulative Update that fixes this issue.

Meanwhile, it’s important remind that all Microsoft platforms are subject of updates (patches) in order to correct / improve its functionality, during the life cycle of their inner versions. Such updates are published periodically (like Service Packs or Cumulative Updates) or according to issues discovered at any time (like hot fixes). For SharePoint Server 2010 products and technologies, the update must consider all inner components (Operating System, SQL, SharePoint Prerequisites, Foundation, Server, and Language Packs) and dependent components (Project Server, SQL Server Reporting Services integrated mode, FAST and so on).

When applying updates for SharePoint 2010 Products and Technologies, it’s important to consider:

• Define, implement and keep an updated documentation of the patch management strategy, according to your IT, Security, Business Continuity policies.

  Microsoft recommends:

• • Keep SharePoint 2010 Products and Technologies updated with the last Service Pack released.

  • Apply Cumulative Updates (CU’s) only when your platform have issues that are fixed with a CU.

• Review Summary and Resolution sections of any Cumulative Update that you plan to apply. Each CU has a Knowledge Base (KB) description page, with key sections:

  • Summary: In this section, you can find a short description about the update, and in some cases, describe known issues that must be addressed after apply the update.

  • Resolution: This section summarize the issues fixed in this CU, the prerequisites to install, restart requirement and file information.

Recommended reading:

Software updates overview (SharePoint Server 2010) http://technet.microsoft.com/en-us/library/ff806329(v=office.14).aspx

Updates for SharePoint 2010 Products (http://technet.microsoft.com/en-us/sharepoint/ff800847.aspx )

Deploy Project Server 2010 updates (http://technet.microsoft.com/en-us/library/gg598486(v=office.14).aspx )