GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

Configurar un Cluster Multi-Site para SQL Server 2012


En el presente artículo describimos la configuración básica de un Cluster Multi-Site sobre Windows Server 2008 R2 y SQL Server 2012 con AlwaysON, una solución de Alta Disponibilidad apropiada para Cluster Geográficos, sin necesidad de tener que utilizar VLANes extendidas (ahorro de costes), aunque con algunos inconvenientes que como veremos en el próximo artículo, se pueden solucionar fácilmente para conseguir un funcionamiento correcto del Cluster Multi-Site.

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.

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.

Esto nos creará un recurso de tipo IP Address en nuestro Cluster, que estará OffLine, y que deberemos configurar

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.

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.

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.

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

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).

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

Hecho esto, finalmente nuestro Cluster quedará configurado con un Recurso Network Name con dependencia sobre dos Recursos de IP Address pertenecientes a Redes diferentes.

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 comprobamos el DNS, podremos ver que existen dos recursos de tipo A para el mismo nombre. Recordemos además que por defecto Round Robin está habilitado

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).

Si editamos cualquiera de estos Recursos A en DNS podremos ver que el TTL está configurado para un tiempo de 20 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.

resolución de nombres DNS con nslookup desde una máquinas Windows Server 2003 R2 ubicada en la VLAN 69: siempre se devolvían los IPs en el mismo orden

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.

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

Tras desactivar la opción Enable Netmask Ordering, conseguimos solucionar este problema. Ahora Round Robin está funcionando correctamente.

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.

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á

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.

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

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.

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.

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.

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.

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.

 


[Fecha del Artículo (UTC): 16/06/2015]
[Autor: GuilleSQL]



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas