• Escrito por 
  • Publicado en Blog
  • 2 comentarios

Microsoft Failover Cluster sobre vSphere 5 y 6

Microsoft Failover Cluster en vSphere

En este Post compartiremos todo lo necesario para una correcta implementación de Microsoft Failover Cluster de Windows Server 2012 R2 sobre vSphere 5 y 6.

Analizaremos los requerimientos, limitaciones, buenas prácticas y configuraciones recomendadas para instalar y configurar el servicio con total seguridad. Incrementaremos la disponibilidad de nuestros servicios y aplicaciones que funcionarán sobre Windows Server 2012 R2 y vSphere.

 

A lo largo del Post nos referiremos a los siguientes terminos:

Nodo: Serán las Maquinas Virtuales que ejecuten los servicios de Microsoft Cluster Services en un Failover Cluster.

Cluster: Se especificará si se hace referencia a un Cluster de vSphere o a un Microsoft Failover Cluster.

Host Cluster: Servidor físico con ESXi que es miembro de un Cluster de DRS y/o HA en vSphere

 

Por qué necesito un Failover Cluster en mi infraestructura?

Antes de responder a esta pregunta revisaremos la siguiente tabla comparativa.

Tabla comparativa HA FT MSCSTabla comparativa entre vSphere HA, vSphere FT y Microsoft Cluster Services

*1: Todos los sistemas operativos soportados por VMware en vSphere

Link: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=software

*2: A partir de Windows Server 2012 se eliminó la edición Enterprise y con la edición Standard viene incluída la funcionalidad de Cluster

*3: Soporte fallos a nivel de Host físico, fallo a nivel de Nodo de Maquina Virtual, Aplicación a nivel de Nodo y además permite ventanas de mantenimiento por Nodo soportando actualizaciones sin detener el servicio

*4: En vSphere 6 es posible habilitar VMCP (VM Component Protection) que protege ante situaciones de PDL y APD aunque la VM cae y el HA reinicia la VM automáticamente

*5: Otra de las novedades en vSphere es la posibilidad de utilizar un Datastore para la maquina primaria y otro diferente para la maquina secundaria. Esto incrementa notablemente la disponibilidad de la Maquina Virtual.

*6: El Microsoft Cluster por si solo no tolera fallos de Almacenamiento aunque al estar sobre vSphere se aprovecha de sus funcionalidades. Se espera para Windows Server 2016 el soporte de alta disponibilidad en Almacenamiento.

 

Habiendo visto la tabla podemos sacar unas simples conclusiones.

vSphere HA: es muy bueno para incrementar la disponibilidad pero si los requerimientos exigen que no haya caída del servicio entonces HA no será nuestra solución. No obstante ayudará a reiniciar automáticamente cualquier nodo que caiga con el Host. Cumple con las tres BBB’s. Bueno. Bonito. Barato. Y funciona!

 

vSphere FT: tiene la limitación de 1vCPU hasta vSphere 5 lo cual supone muy pocos recursos de CPU para maquinas críticas. En vSphere 6 FT viene realmente muy mejorado incrementando hasta 2 vCPU’s (Standard y Enterprise) y 4 vCPU’s (Enterprise Plus), además de la posibilidad de utilizar almacenamientos diferentes para las VMs primaria y secundaria. No obstante si necesitamos asegurar un SLA que exige una ventana de mantenimiento para actualizar software (reinicio incluído) sin detener el servicio, entonces FT tampoco cumplirá nuestras expectativas.

 

MSCS: Si hablamos de aplicaciones y servicios que funcionan sobre Windows Server y las limitaciones no resultan un impedimento, es muy probable que con Microsoft Cluster Services, en combinación con vSphere, podamos cumplir con el SLA requerido al presentar diferentes servicios y aplicaciones sobre Microsoft Cluster Services.

 

He aquí la importancia de la combinación de MSCS y vSphere y del porqué de este Post.

Sigamos con las diferentes modalidades de MSCS que nos podemos encontrar.

 

Modalidades de Cluster

Existen tres tipos de Cluster de Microsoft que podemos desplegar sobre vSphere:

Modos de Microsoft Failover Cluster en vSphere
Diferentes modos de un Microsoft Cluster combinando físico y virtual

CIB (Cluster in a Box):Todos los Nodos (Maquinas Virtuales) del Cluster funcionando sobre el mismo Host físico.

 

CAB (Cluster Across Box): Todos los Nodos del Cluster funcionando sobre Hosts físicos diferentes.

 

PaV (Physical and Virtual): Combinación de Nodos funcionando sobre maquina física y maquina virtual.

 

Se me hace difícil comprender algún caso de alguna empresa que decidiera poner en producción un Cluster en modo CIB aunque hay políticas para todos los gustos.

En el caso que tuviésemos ganas de complicarnos la vida gratuitamente (para qué fácil si difícil se puede?) podríamos configurar un PaV compuesto por un Server físico y una o más Maquinas Virtuales, ambos como nodos del Failover Cluster.

Es por esto que el MSCS más desplegado hoy por hoy es el CIB y de eso se trata este Post.


Requerimientos y Limitaciones de MSCS Windows Server 2012 R2 en vSphere 5 y 6

A continuación detallaremos los requerimientos y las limitaciones para desplegar un Microsoft Failover Cluster de Windows Server 2012 R2 en modo CIB (Cluster Across Box) sobre vSphere, tanto en versión 5 Update 2 como en versión 6x.

 

Requerimientos MSCS Windows Server 2012 R2 en VMware vSphere 


Requerimientos MSCS en vSphere 5 y 6
Requerimientos de Windows Cluster Services en vSphere

*1: En vSphere 5.5U2 está soportado Round Robin como PSP para la LUN del/los discos RDM aunque es posible que durante la validación del Cluster aparezca una alerta.

Si bien está soportada la presentación mixta de las LUNs utilizando diferentes PSP en los Hosts que dan soporte a las VMs que funcionan como Nodos del MSCS, se recomienda utilizar los mismos PSP’s para, al menos, las LUNs de RDM en todos los Hosts.

 

 Limitaciones MSCS Windows Server 2012 R2 en VMware vSphere 

Limitaciones en MSCS sobre vSphere 5 y 6
Limitaciones en Windows Cluster Services sobre vSphere 5 y 6

Si bien las limitaciones se ven razonables debemos respetarlas a rajatabla.

La limitación de Datastore VMFS es debido a que cuando presentamos un disco RDM utilizamos un Datastore VMFS para almacenar un archivo que funciona como puntero a la LUN.

En el caso de la presentación en modo físico es para que los nodos del cluster que acceden de forma compartida a un almacenamiento en común gestionen las reservas utilizando SCSI 3 (Persistent Reserve commands).


Buenas practicas MSCS Windows Server 2012 R2 en VMware vSphere 5/6

Buenas practicas en MSCS sobre vSphere 5 y 6
Buenas practicas en Windows Cluster Services sobre vSphere 5 y 6

Como vemos tenemos una larga lista de buenas prácticas a aplicar. Cada una con su correspondiente razón y sólo en algunos casos dependerá de la infraestructura que tengamos debajo.

 

Otra vez mas, ha sido un placer. Como siempre espero que te haya resultado útil. Comentarios, consultas, sugerencias? Me ayudas a compartirlo?

 

2 comentarios

  • Ivan Mantilla
    Ivan Mantilla Lunes, 01 Febrero 2016 01:42 Enlace al Comentario

    He visto muchos problemas con vSphere 5.5 en donde los discos al momento de hacer failover fallan diciendo que están en uso, Vmware recomienda utilizar las versiones VMware ESXi 6.0 Update 1 o
    VMware ESXi 5.5 patch ESXi550-201512001, por bugs en la presentación de los discos RDM en modo físico. Aquí el KB
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2114741

    Saludos, muy buen post

  • Rolando Kohl
    Rolando Kohl Jueves, 28 Enero 2016 14:31 Enlace al Comentario

    jajaja, me acorde fede que en vSphere 4 instalamos un MSCS Win2k3 con PaV y realmente luchar con los reescaneos de LUNs, y Scsi reservations, es complicarse la vida.

    Hoy tengo un Cluster SQL 2k8 con Win2k8 y funciona de pelos con la solucion CAB

Deja un comentario

Muchas gracias por tus comentarios!!
Tras la revisión rutinaria, será publicado.

Utilizamos cookies propias y de terceros para facilitar y mejorar nuestros servicios. Al navegar por nuestra página web aceptas nuestras cookies.

Para más información, o para conocer cómo cambiar la configuración, lee nuestra Política de cookies. Saber más

Acepto

Mis Partners