Buenos días,

 

Voy a compartir con vosotros algunos de los pasos que sigo para intentar identificar donde está la causa de un problema concreto.

 

PROBLEMA

=========

Tenemos un cluster de 2 nodos con Windows Server 2008, y una instancia de SQL Server 2008 en cluster.

La instancia funciona perfectamente en el Nodo1. Hacemos un balanceo de la instancia al Nodo2. Al intentar levantar la instancia en el Nodo2, nos encontramos con que el recurso falla y se hace un failover automático al Nodo1.

La instancia VSERVER\VINSTANCE escucha por Named Pipes, TCPIP (en ip 157.58.114.35, puerto 3650)

Paso 1

=====

- Pongo los recursos offline en el Nodo1

- Hago un failover al Nodo2

- Pongo los recursos online (1 tras otro)

El recurso que falla es SQL Server.

Los errorlog de la instancia muestran también que sí se levanta la instancia, y que para de la manera siguiente:

2009-07-22 14:45:57.21 spid7s      Recovery is complete. This is an informational message only. No user action is required.

   :   :   :   :   :   :   :

2009-07-22 14:49:28.08 spid14s     Service Broker manager has shut down.

2009-07-22 14:49:28.60 spid7s      SQL Server is terminating in response to a 'stop' request from Service Control Manager. This is an informational message only. No user action is required.

2009-07-22 14:49:28.60 spid7s      SQL Trace was stopped due to server shutdown. Trace ID = '1'. This is an informational message only; no user action is required.

Siempre puedo comprobar que la instancia se levanta durante 3m30s. El errorlog nos muestra que si SQL Server para es porque alguien le ha pedido que se pare.

En el periodo de tiempo en que la instancia está levantada, se pueden ver los errores siguientes en el log de aplicación:

Error            7/22/2009 2:46:07 PM                 MSSQL$NLZEI06011 19019         Failover     "[sqsrvres] checkODBCConnectError: sqlstate = 08001; native error = 274d; message = [Microsoft][SQL Server Native Client 10.0]A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.

"

Error            7/22/2009 2:46:07 PM                 MSSQL$VINSTANCE  19019         Failover     "[sqsrvres] ODBC sqldriverconnect failed

"

Error            7/22/2009 2:46:07 PM                 MSSQL$VINSTANCE 19019         Failover     "[sqsrvres] checkODBCConnectError: sqlstate = HYT00; native error = 0; message = [Microsoft][SQL Server Native Client 10.0]Login timeout expired

"

Error            7/22/2009 2:46:07 PM                MSSQL$VINSTANCE  19019         Failover     "[sqsrvres] ODBC sqldriverconnect failed

"

Error            7/22/2009 2:46:07 PM                 MSSQL$VINSTANCE 19019         Failover     "[sqsrvres] checkODBCConnectError: sqlstate = 08001; native error = 274d; message = [Microsoft][SQL Server Native Client 10.0]TCP Provider: No connection could be made because the target machine actively refused it.

 

"

Error            7/22/2009 2:46:07 PM                 MSSQL$VINSTANCE  19019         Failover     "[sqsrvres] ODBC sqldriverconnect failed

 

Paso 2

=====

Al levantar la instancia en el Nodo2, en realidad, la instancia de SQL Server sí levanta, y consigo conectarme a ella utilizando la cadena de conexión TCP:157.58.114.35, 3650, pero no por el nombre VSERVER\VINSTANCE.

Por alguna razón, el proceso de IsAlive del cluster considera que la instancia de SQL Server está caída y decide apagarla y hacer el failover. Por lo que tenemos básicamente un problema de conexión a la instancia.

 

Paso 3

=====

Verifico en el errorlog de SQL Server que la instancia está escuchando por la ip 157.58.114.35 y el puerto 3650.

En el Nodo2, ejecuto el SQL Server Configuration Manager y verifico si tenemos algún alias.

Efectivamente, existe un alias TCP con la información siguiente:

Nombre de alias: VSERVER\VINSTANCE

Nombre de servidor: 157.58.114.35

Puerto: 365

El servicio de cluster, al querer conectarse a la instancia, utiliza este alias (creado previamente a mano, que NO existe en el Nodo1) y no lo consigue.

 

SOLUCION

=========

Podemos definir el alias con el puerto correcto, o directamente eliminat el alias.

 

Un saludo!

Marcos Celada

Ingeniero de Soporte de SQL Server