Windows Server 2012: Failover Cluster para Hyper-V (Parte 1 – Creando la Infraestructura)

Hace algún tiempo hice una nota con la misma finalidad que esta, crear en Windows Server 2012, un Failover Cluster pero dejé todo luego de realizar sólo la primera parte. Aunque la configuración de dicha nota fue correcta, en realidad está muy relacionada a las anteriores implemntaciones del sistema operativo, cuando a partir de Windows Server 2012, lo podemos hacer no sólo más sencillo, sino que además veremos nuevas funcionalidades

Es de fundamental importancia comenzar con una buena base, así que en esta nota veremos cómo configurar las máquinas necesarias, la mínima cantidad como para este paso a paso, verificar la correcta configuración de las mismas, y crear el medio que usaremos de almacenamiento (iSCSI Target)

Los equipos que utilizaremos son cuatro: un Controlador de Dominio (necesitamos Dominio para implementar Failover Cluster), dos servidores miembros del Dominio que serán los nodos del Cluster (HYPER1 e HYPER2), y por último lo que utilizaremos como SAN que no es otra cosa que un Windows Server 2012 con iSCSI Target, ya que ahora viene incluido en el sistema operativo

Pienso que lo mejor para ser claro es incluir una figura con el diseño de conectividad entre los equipos, ya que necesitaremos tres redes que yo he nombrado de la siguiente forma:

  • DomainNet: conocida como “red pública”, es la red que utilizarán los clientes para acceder al Cluster
  • HeartbeatNet: es la red que permite la comunicación interna entre los nodos del Cluster
  • SANNet: que corresponde a la red que utilizarán los nodos del Cluster para conectarse por iSCSI a el dispositivo de almacenamiento (SAN)

Otro detalle importan es la selección de direcciones IP a utilizar, ya que debemos tener en cuenta que necesitaremos tres subredes diferentes. Muestro las que yo he elegido, pero por supuesto pueden usar las que crean más convenientes. Luego del cuadro aclararé algunos puntos importante en cuanto al manejo de redes que hace Windows Server 2012 y que debemos solucionar

Es un problema que Windows Server 2012 no nos permita elegir a nuestra necesidad si una red es pública o privada, o mejor dicho nos impone ciertas condiciones. Una de ellas es que si no hay configurado Default Gateway, considera que la red es pública, y por lo menos yo, no he encontrado la forma de pasarla a red de trabajo :-(

Y necesitasmos que estas redes (HeartbeatNet y SANNet) sean consideradas redes de trabajo

La solución que he encontrado fue ponerle un innecesario Default Gateway apuntando a otro equipo de la misma red. Pero esto nos puede traer otros problemas ya que podrían interferir con el Default Gateway que realmente necesitamos y está configurado sobre la DomainNet

¿Qué hecho para solucionarlo? En la configuración de Default Gateway de HeartbeatNet y SANNet le he quitado la métrica automática, y le he puesto a mano 500. Un valor lo suficientemente alto para que no interfiera

Aún así, el sistema sigue considerando a las redes como públicas, así que tenemos que hacer algo más. Pulsamos sobre el icono de red de la barra de tareas y nos aparecerán a la derecha las redes. Con botón derecho sobre cada una de ellas habilitemos el compartir archivos e impresoras (es necesario)

Por último, y muy importante antes de seguir adelante verifiquemos que no tenemos problemas de conectividad, en mi caso provisoriamente desactivé los cortafuegos de todas las máquinas y verifiqué conectividad con PING <DirIP>

Estando todo bien, volví a levantar todos los cortafuegos

Si lo están haciendo con máquinas virtuales, como yo, es momento de hacer un “snapshot”
En el caso de estar haciendo en virtuales, recuerden que para poder hacer el cluster de Hyper-V necesitarán poder hacer “virtual dentro de virtual” y no todos los sitemas lo permiten

 

Notas Relacionadas:

Windows Server 2012: Failover Cluster para Hyper-V (Parte 2 – Configurando la SAN) | WindowServer: https://windowserver.wordpress.com/2012/11/22/windows-server-2012-failover-cluster-para-hyper-v-parte-2-configurando-la-san-test3/

Windows Server 2012: Failover Cluster para Hyper-V (Parte 3 – Configurando los iSCSI Initiators) | WindowServer: https://windowserver.wordpress.com/2012/11/23/windows-server-2012-failover-cluster-para-hyper-v-parte-3-configurando-los-iscsi-initiators/

Windows Server 2012: Failover Cluster para Hyper-V (Parte 4 – Instalando la funcionalidad Failover Cluster e Hyper-V) | WindowServer: https://windowserver.wordpress.com/2012/11/23/windows-server-2012-failover-cluster-para-hyper-v-parte-4-instalando-la-funcionalidad-failover-cluster-e-hyper-v/

Windows Server 2012: Failover Cluster para Hyper-V (Parte 5 – Creando y Configurando el Failover Cluster) | WindowServer: https://windowserver.wordpress.com/2012/11/23/windows-server-2012-failover-cluster-para-hyper-v-parte-5-creando-y-configurando-el-failover-cluster/

Windows Server 2012: Failover Cluster para Hyper-V (Parte 6 – Creando una Máquina Virtual con Alta Disponibilidad) | WindowServer: https://windowserver.wordpress.com/2012/11/23/windows-server-2012-failover-cluster-para-hyper-v-parte-6-creando-una-mquina-virtual-con-alta-disponibilidad/

Windows Server 2012: Servidor de Archivos con Disponibilidad Continua (Continuous Availability File Server) [Y un Tip] | WindowServer: https://windowserver.wordpress.com/2012/11/30/windows-server-2012-servidor-de-archivos-con-disponibilidad-continua-continuous-availability-file-server-y-un-tip/

Post a comment or leave a trackback: Trackback URL.

Comentarios

  • Edward  On 25/06/2013 at 20:06

    Hola, tengo una consulta:
    Puede crear un Cluster Hyper-V 2012 con dos Nodos + 1 storage tipo DAS? (Direct Attached Storage)
    Lei en technet de microsoft que es imposible en 2008 R2 pero con 2012 hay una luz de esperanza =)

    Gracias te antemano

    • Delprato  On 26/06/2013 at 09:05

      Hola
      Si te refieres al DAS en los nodos, la respuesta es: no se puede.
      Todos los nodos del un Cluster deben poder acceder a un medio compartido lo que no es el caso en el DAS de cada nodo

      Respecto a lo que en la nota nombro como “SAN”, este equipo usa sus discos internos (DAS), y los ofrece a los nodos

      No sé si respondí bien la pregunta, tengo dudas. Si no fuera así por favor avísame

      • Edward  On 26/06/2013 at 12:22

        Gracias por la respuesta,
        Quisiera saber que alternativa tendria, quizas con Windows 2012? el SMB3.0 me podria ayudar?
        Ya tengo los equipos, lamentablemente.

        Gracias

      • Delprato  On 26/06/2013 at 13:00

        SMB 3.0 es una gran opción, pero no para lo que propones
        El objetivo de un Cluster es la alta disponibilidad, o sea tolerancia a fallas
        Supongamos un caso simple, un cluster de dos nodos. La idea es que si uno de los nodos falla, el otro asuma la función ¿estamos de acuerdo si?
        Si el almacenamiento estuviera en el nodo que falla, estamos en problemas :-) el cluster no cumple la función

        Otra alternativa diferente que puede proveer tolerancia a fallas, sobre máquinas virtuales con Hyper-V y sin tener medio de almacenamiento compartido, es el uso de “Replica Virtual Machines”
        Revisa el siguiente enlace a ver si te sirve
        Windows Server 2012 – Demostración: Hyper-V Réplica de Máquina Virtual (Replica Virtual Machine) | WindowServer:
        https://windowserver.wordpress.com/2012/05/03/windows-server-2012-demostracin-hyper-v-rplica-de-mquina-virtual-replica-virtual-machine/

      • Edward  On 26/06/2013 at 13:43

        Gracias, una consulta más.
        Si tuviera un tercer servidor, al cual iria conectado el DAS y lo convierto en un iSCSI Target con Windows o un SMB, ahi si podria funcionar no?

        Gracias

      • Delprato  On 26/06/2013 at 14:48

        Exactamente :-)
        Eso es justamente lo que he hecho en la nota

  • Ramón González  On 14/09/2013 at 22:16

    Hola,

    ¿Puedo usar su solución de colocar como Default Gateway a otro equipo de la misma red en un Cluster en producción?

    ¿Cuál ha sido su experiencia en ambientes reales haciendo esto?

    ¿Encontró otro método para solucionar este impase?

    Gracias anticipadas…

    • Guillermo Delprato  On 15/09/2013 at 08:32

      Hola Ramón, primero que nada recordemos que el objetivo de la nota es una demostración; la implementación en un ambiente productivo depende del propio ambiente productivo, sus condiciones y los servicios que prestará. No existe en esto la “receta general aplicable a todos los casos”
      El uso de múltiples Default Gateway es un tema que hay que solucionar y por eso a las que no quiero que utilice le he puesto una métrica mucho mayor con el objetivo de pasar la red a Privada. No es la única solución, también se puede hacer por GPO para que las redes desconocidas las tome como privadas:
      Computer Configuration / Windows Settings / Security Settings / Network Lista Manager Policies / Unidentified Networks

      Si el tema realmente te preocupa revisa el siguiente enlace que tiene mucha información sobre el tema: Network Location Awareness (NLA) and how it relates to Windows Firewall Profiles – Microsoft Enterprise Networking Team – Site Home – TechNet Blogs:
      http://blogs.technet.com/b/networking/archive/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles.aspx

  • Juan Carlos Heredia Mayer  On 11/02/2014 at 19:09

    Estupenda guía de estudio. Gracias por compartirla.

  • Federico De Luca  On 02/09/2014 at 12:06

    Buenas Guillermo, te molesto con unas últimas consultas.

    Qué función cumple la conexión “HeartbeatNet”?
    Daría algún problema que el SAN estuviera en la DomainNet en vez de en una red particular?
    Por qué recomendás no unir el SAN al dominio?

    Gracias desde uay

    • Guillermo Delprato  On 02/09/2014 at 12:13

      Federico, por la “HearthbeatNet” se comunican los nodos del cluster, es la que usan para detectar la caída de alguno de los nodos
      Que la SAN pertenezca al dominio no tendría probleas, salvo que en ese caso debería estar también conectada a la “DomainNet”, y por lo tanto alguno podría accederla directamente. El tenerla en una red separada, y teniendo en cuenta que los nodos no “rutean” es más que nada una medida de seguridad

Trackbacks

Este espacio es para comentarios sobre la nota. No es un sitio de soporte

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: