En Windows Server 2008 FailOver Cluster se introdujo la posibilidad de poder montar un Cluster Multi-Site, sin tener que recurrir a tecnologías externas como VLAN Extension, una característica que se ha mantenido en versiones posteriores (Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, etc).
Descripción del Escenario
Partimos de un FailOver Cluster de SQL Server 2012 sobre Windows Server 2008 R2, formado por tres Nodos (VSQL2012A, VSQL2012B, VSQL2012C) prestando un servicio de AlwaysON, los dos primeros con una Instancia Clusterizada con Discos Compartidos (VSQL2012\INST_01), y el tercero con una Instancia StandAlone (VSQL2012C\INST_02). AlwaysON está configurado con un Listener, con nombre lstAG_GuilleSQL, y Dirección IP 192.168.69.90. Por lo tanto, tenemos dos Grupos de Recursos en nuestro Cluster, uno para la Instancia de SQL clusterizada (VSQL2012\INST_01) y otro para el Listener de AlwaysON (lstAG_GuilleSQL).
Este Cluster estaba inicialmente configurado con todos los Nodos en la misma VLAN (192.168.69.0/24), por lo que hemos cambiado la Dirección IP del tercer nodo para que pertenezca a otra VLAN (192.168.72.0/24), incluyendo la configuración de Gateway y de routing de tráfico. Al cambiar la Dirección IP, el FailOver Cluster detecta una nueva Red, así que hemos dejado todas Red con un nombre descriptivo (HB, LAN 69, y LAN 72).
Sobre este escenario, en el que tan sólo hemos cambiado la Dirección IP de uno de los Nodos (VSQL2012C) para que pertenezca a una VLAN distinta, necesitamos realizar la configuración completa de un Cluster Multi-Site. En este escenario de partida, el Grupo de Recursos del Listener de AlwaysON (AG_GuilleSQL), no será capaz de arrancar en el tercer Nodo (VSQL2012C), ya que este Nodo sólo ve la Red 192.168.72.0/24, mientras que la IP del Listener pertenece a la Red 192.168.69.0/24.
Configuración del Cluster Multi-Site en Windows Server 2008 R2
Dado que nuestro Grupo de Recursos de Cluster tiene configurada una única dirección IP en la VLAN 69, deberemos añadir otra dirección IP en la VLAN 72 y configurarla con una dependencia sobre el Recurso de Network Name, con una relación OR entre ambas IPs, de tal modo, que el Cluster intentará arrancar una Dirección IP o la otra, para seguidamente arrancar el Recurso de Network Name.
Para añadir un nuevo Recurso de dirección IP, sobre el Grupo de Recursos del Cluster, seleccionaremos la opción Add a resource -> More resources -> Add IP Address del menú contextual.
Esto nos creará un recurso de tipo IP Address en nuestro Cluster, que estará OffLine, y que deberemos configurar. Para ello, seleccionaremos la opción Properties del menú contextual.
En el diálogo de configuración del nuevo Recurso de tipo IP Address, deberemos al menos asignar un nombre al Recurso, especificar la Red, y especificar la dirección IP.
Realizado esto, ya tendremos configurado nuestro nuevo Recurso de tipo IP Address para la nueva Red, pero aún sigue como un Recurso totalmente independiente.
Necesitamos configurar el Recurso de Network Name, para especificar una relación de dependencia con el nuevo Recurso de tipo IP Address, de tal modo, que primero se levante la IP, y seguidamente el Nombre, que es lo correcto.
En el diálogo de Propiedades del Recurso de Network Name, añadiremos el Recurso de IP Address que acabamos de crear, especificando una relación OR entre ambas IPs, de tal modo, que siempre se levante una Dirección IP (la correcta, dependiendo de la IP del Nodo en que se levante el Grupo de Recursos), y no sea requisito que se levanten ambas Direcciones IP (algo que no podrá ocurrir, al pertenecer a Redes diferentes).
Hecho esto, finalmente nuestro Cluster quedará configurado con un Recurso Network Name con dependencia sobre dos Recursos de IP Address pertenecientes a Redes diferentes.
Con esto, la configuración básica de nuestro Cluster Multi-Site ha finalizado.
Comenzando las Pruebas del Cluster Multi-Site
Sin hacer nada más que lo descrito hasta el momento en el presente artículo, hemos probado a balancear el Grupo de Disponibilidad de AlwaysON al tercer Nodo (desde las opciones de AlwaysON de SQL Server Management Studio), y seguidamente devolverlo al Cluster, y el balanceo ha funcionado OK. En todos los casos, sólo se ha puesto OnLine la IP correspondiente a la Red en la que se levantaba el Network Name, y la otra IP se ha quedado OffLine. Hasta este punto, era lo esperado. Fenomenal.
Si comprobamos el DNS, podremos ver que existen dos recursos de tipo A para el mismo nombre (en nuestro caso, estamos hablando del nombre del Alias de AlwaysON, que es el que se tendrá que balancear entre ambos Sites, es decir, deberá poder cambiar de IP). Recordemos además que por defecto Round Robin está habilitado, al menos en nuestro caso, un DNS de Windows Server 2003 R2. Ya hablamos anteriormente del DNS Round Robin y la Caché DNS de Cliente (TTL).
Si editamos cualquiera de estos Recursos A en DNS podremos ver que el TTL está configurado para un tiempo de 20 minutos, valor por defecto para los registros A que se han creado por un Cluster (los creados a mano, por defecto se quedan configurados a 60 minutos).
El hecho de que se registren varias direcciones IP para el mismo nombre en DNS, no parece una solución muy apropiada, y Round Robin tampoco parece que sea se ayuda, ya que hablamos de un escenario en el que sólo una de dichas direcciones IP está levantada, por lo que es previsible que se puedan producir intentos de conexión fallidos, al intentar conectar contra la dirección IP que está OffLine. No obstante, vamos a hacer algunas pruebas más específicas, a ver qué nos encontramos.
Probando desde un Windows Server 2003 R2 (VLAN 69 - ISA Server 2004)
Lo primero que nos hemos encontrado al probar la resolución de nombres DNS con nslookup desde una máquinas Windows Server 2003 R2 ubicada en la VLAN 69 (la misma en la que está el Controlador de Dominio y el Cluster), es que siempre se devolvían los IPs en el mismo orden, por lo que parece que Round Robin no estaba funcionando como se esperaba.
Esto es debido a la opción Netmask Ordering de DNS, que al igual que Round Robin, es una opción de configuración Global del Servidor DNS. Esta opción por defecto está habilitada, y permite devolver las direcciones IP en un orden determinado en función de la IP del cliente DNS que realiza la consulta, con la intención de que la primera IP devuelta sea la más cercana al equipo que realiza la consulta DNS (habitualmente, sólo se utiliza la primera IP devuelta, y se ignoran el resto de IPs). Por este motivo, como el equipo cliente DNS está en la VLAN 69, siempre estaba devolviendo primero la IP de la VLAN 69 seguida de la IP de la VLAN 72, sin alternar nunca el orden de los resultados.
Tras desactivar la opción Enable Netmask Ordering, conseguimos solucionar este problema. Ahora Round Robin está funcionando correctamente.
Sin embargo, ahora nos hemos encontrado con errores aleatorios de resolución DNS, ya que dependiendo del orden en que se devuelvan las IPs, funcionará el PING o no funcionará. Como evidencia, a continuación se pueden ver varios PING separados del comando ipconfig /flushdns para vaciar la caché local DNS y que se realice una nueva consulta DNS. Cada vez, toma una IP, pero como sólo una IP está activa, unos PING funcionan y otros no.
El mismo comportamiento es el que nos hemos encontrado al utilizar un fichero UDL para comprobar el acceso a SQL Server. En unas ocasiones funciona, y otras no, dependiendo de la resolución DNS y el orden en que son devueltas las direcciones IP.
Probando desde un Windows Server 2003 R2 (VLAN 69 - Controlador de Dominio y DNS)
Al probar desde un Windows Server 2003 R2 localizado en la VLAN 69 (la misma de las dos máquinas del Cluster) que actuaba como Controlador de Dominio y DNS, hemos experimentado un comportamiento distinto al anterior. En este caso, hemos podido comprobar con nslookup que las direcciones IP se devolvían en orden alternos en cada consulta, por lo que Round Robin estaba funcionando OK, independientemente de la opción de Netmask Ordering (lo probamos con Netmask Ordering activado y desactivado, y nslookup devolvía las IPs en orden alterno en todos los casos).
Sin embargo, aun así, nos hemos encontrado que todos los intentos de PING son realizados contra la IP en la misma Red en la que está el Controlador de Dominio.
Igualmente, hemos creado un fichero UDL, para conectarse a SQL Server, pero hemos detectado que siempre se intentaba conectar a la misma IP (como si estuviese activado el Netmask Ordering), por lo que ante un balanceo del Cluster, la conectividad con SQL Server dejaría de funcionar.
Probando desde un Windows Server 2012 (VLAN 69)
Al hacer las correspondientes pruebas desde un Windows Server 2012 con SharePoint 2013, hemos comprobado con nslookup que Round Robin estaba funcionando correctamente, devolviéndose las direcciones IP en orden alterno entre cada llamada.
Sin embargo, afortunadamente, aunque el orden en que son devueltas las IPs sea alterno, el funcionamiento es correcto, y al ejecutar varios PING vaciando la caché local de DNS entre medias, siempre resuelve contra la dirección IP correcta (la única que está OnLine) y el PING se realiza siempre satisfactoriamente.
Conclusiones
En el presente artículo, hemos visto la configuración básica de un Cluster Multi-Site, que posteriormente hemos probado, detectando varios problemas consecuencia de la existencia de varias IPs registradas en DNS pare el Network Name del SQL, cuando sólo una IP está activa (y el resto están OffLine, por lo que no responden). Si bien, ha habido casos en los que ha funcionado correctamente, en otros ha sido un desastre. En el siguiente artículo explicaremos la solución: Configurar las opciones RegisterAllProvidersIP y HostRecordTTL del Recurso Network Name en un Cluster Multi-Site.
Poco más por hoy. Como siempre, confío que la lectura resulte de interés.
