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

Data Collector, SQL Server 2008 R2, FileServer, Cluster, errores de conexión, y Sockets en TIME_WAIT


Estos días me he estado pegando con un problema de red en un Failover Cluster de Windows Server 2008 R2 con dos instancias de SQL Server 2008 R2 y un FileServer en un Cluster de Windows Server 2008 R2. Tras gran cantidad de errores de backup y de monitorización (en los Agentes que se ejecutaban localmente en los Nodos del Cluster), errores de conexión con SQL Server Management Studio (a SQL Server y Analysis Services), y multitud de caídas sin motivo aparente del recurso de FileServer, al final, el problema fue el Data Collector. Alucina.

Hacía mucho que no me encontraba con un problema tan desconcertante.

Estamos hablando de un Failover Cluster de Windows Server 2008 R2 formado por 2 Nodos, sobre el cual está corriendo un Grupo de Recursos con un FileServer (con su nombre, su IP, y sus LUNes), y dos Grupos de Recursos con SQL Server 2008 R2 y Analysis Services (es decir, cada Grupo de Recursos tiene su nombre, su IP, sus LUNes, su SQL Server, y su Analysis Services).

El recurso de FileServer se caía aleatoriamente sin motivo aparente. Incluso en alguna ocasión, aunque de forma mucho más esporádica, se caía el recurso de tipo Name (esto último dejó de ocurrir, quizás por alguna actualización).

A las instancias de SQL Server y de Analysis Services, no podías conectarte desde los propios Nodos del Cluster de forma eventual, aunque al reintentar, podías conectarte OK si hacer nada más. Bueno, al principio no sabíamos que no te podías conectar sólo desde los Nodos del Cluster, eso lo averiguamos al final.

Problemas del Recurso de FileServer

El recurso de FileServer se caía aleatoriamente sin motivo aparente (es más, y sin usuarios ni datos en la única carpeta compartida que tenía). En los eventos del Cluster, en la consola de Failover Cluster Manager, podíamos encontrar en cada caída eventos 1587 y 1069 (ambos con Source de Microsoft-Windows-FailoverClustering) asociados al recurso FileServer, que francamente, no resultaban de mucha utilidad. La información que mostraban era similar a los siguientes ejemplos:

  • Event 1587 (Source de Microsoft-Windows-FailoverClustering). Cluster file server resource 'FileServer-(GuilleSQLFileServer)(Cluster Disk 10)' failed a health check. This was because some of its shared folders were inaccessible. Verify that the folders are accessible from clients. Additionally, confirm the state of the Server service on this cluster node using Server Manager and look for other events related to the Server service on this cluster node.
  • Event 1069 (Source de Microsoft-Windows-FailoverClustering). Cluster resource 'FileServer-(GuilleSQLFileServer)(Cluster Disk 10)' in clustered service or application ' GuilleSQLFileServer' failed.

Además, en alguna ocasión mucho más esporádica se caía el recurso de tipo Name, encontrando los eventos 1069 y 1207 (ambos con Source de Microsoft-Windows-FailoverClustering) asociados al recurso de tipo Name. Esto ocurría sobre todo al principio. Más adelante dejaron de aparecer estos errores, aunque a saber porqué (es decir, se montaron algunas KB entre medias, se volvió a eliminar y crear el Grupo de Recursos de FileServer, se corrigieron permisos en cuentas de equipo de Directorio Activo y en registros DNS, etc.). La información que mostraban era similar a los siguientes ejemplos:

  • Event 1069 (Source de Microsoft-Windows-FailoverClustering). Cluster resource 'GuilleSQLFileServer' in clustered service or application 'GuilleSQLFileServer' failed.
  • Event 1207 (Source de Microsoft-Windows-FailoverClustering). Cluster network name resource 'GuilleSQLFileServer' cannot be brought online. The computer object associated with the resource could not be updated in domain 'guillesql.local' for the following reason: Unable to get Computer Object using GUID. The text for the associated error code is: The server is not operational. The cluster identity ' GuilleSQLFileServer$' may lack permissions required to update the object. Please work with your domain

Otra cosa que mosqueaba, es que en alguna ocasión, al dejar la consola de Failover Cluster Manager abierta en uno de los Nodos del Cluster (a través de una conexión RDP), más tarde, al volver a dicha sesión RDP, te encontrabas con la consola de Failover Cluster Manager sin conexión con el Cluster, es decir, algo como lo siguiente.

Al dejar la consola de Failover Cluster Manager abierta en uno de los Nodos del Cluster (a través de una conexión RDP), más tarde, al volver a dicha sesión RDP, te encontrabas con la consola de Failover Cluster Manager sin conexión con el Cluster

Creo que cuando ocurría esto, se registraba el Event 4630 (Failover Cluster Manager was disconnected from cluster 'GuilleSQLClus'. Please make sure the cluster is up and accessible), pero no estoy seguro, ya que en este evento me fijé después, y no pondría la mano en el fuego en relacionar ambas cosas.

En otras ocasiones, te encontrabas en la consola de Failover Cluster Manager el mensaje de Failed to retrieve the resources in this service or application, sin conseguir mayor detalle de información (salvo la palabra unavailable por doquier), también de forma aleatoria, y tras breves instantes, se recuperaba sólo (cual Juan Palomo).

Failed to retrieve the resources in this service or application

Otro mensaje de error que se podía encontrar de forma aleatoria en la consola de Failover Cluster Manager, era el siguiente: The Client Access point is not yet available. This may be due to network propagation delays, please try refresh after a few minutes.

: The Client Access point is not yet available. This may be due to network propagation delays, please try refresh after a few minutes

Había otro error, que sin llegar a ser propio del FileServer, surgía la duda de cuanto podría llegar a estar relacionado con él. Se trataba del siguiente error de NetLogon, que daba la sensación de que no había ningún DC disponible, cuando todos los DCs estaban levantados y dando servicio, es más, con dos DCs en la misma VLAN en la que estaba el Cluster.

  • Event 5719 (Source de NETLOGON). This computer was not able to set up a secure session with a domain controller in domain GUILLESQL due to the following: The RPC server is unavailable. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

En fin, esto es solo parte del muestrario de errores y mensajes sufridos por el Grupo de Recursos dedicado al FileServer.

Lo desconcertante de todo esto, es que todo parecía ser un problema de comunicaciones. Sin embargo, no había ningún problema de red (ni a nivel de los puertos de cada switch, ni a nivel de VLANs, ni a nivel de enrutamiento, ni a nivel de Firewall, ni el tamaño de MTU, etc.).

Los problemas persistían, tanto utilizando el Teaming como sin Teaming, tanto activando las opciones de TCP/UDP Offload como sin activarlas, etc.

Las versiones de los drivers de las tarjetas de red, eran las correctas. El Firmware estaba en matriz de compatibilidad. No existían problemas conocidos entre las tarjetas de red y el Switch del bastidor (enclosure), etc.

Pero aún así, seguía pareciendo un problema de red, local a la máquina, ya que la sensación era como si los Nodos del Cluster pudieran quedarse aislados (a nivel Ethernet) durante un instante, y luego recuperarse y continuar trabajando correctamente.

Sin embargo, esto no ocurría en el resto de VMs de la misma VLAN. Es más, el resto de VMs de la misma VLAN estaban accediendo OK a las instancias de SQL Server.

Problemas de conexión a SQL Server y Analysis Services

En el caso de SQL Server y Analysis Services, el tema era parecido. Conectado por RDP a los Nodos del Cluster, al conectarse con SQL Server Management Studio o con el SQL Profiler, en ocasiones (aleatoriamente) se presentaba algún error de conexión como el siguiente: Login timeout expired. A network-related or instance-specific errer 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. Named Pipes Provider: Could not open a connection to SQL Server.

Login timeout expired. A network-related or instance-specific errer 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. Named Pipes Provider: Could not open a connection to SQL Server

Sin hacer nada, al reintentar después, podías conectarte OK. Además, si había previamente alguna conexión a la instancia de SQL Server, esta no se veía afectada. Tampoco existía ningún problema de rendimiento.

En una ocasión, conectado con el SQL Server Management Studio a una de las instancias de Analysis Services, al intentar mostrar el diálogo de propiedades de la instancia de Analysis Services, se presentó el siguiente mensaje de error: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full 192.168.69.72:2382

An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full 192.168.69.72:2382

Este error fue el único que sirvió de ayuda, al menos, para empezar a pensar en posibles problemas de comunicaciones relacionados con los Sockets, después de leer la siguiente entrada de un Blog Microsoft MSDN: Understanding the error “An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.”

Al margen de todo esto, existían problemas aleatorios de conexión a SQL Server, tanto por el Software de Monitorización como por el Software de Backup. En ambos casos, existían Agentes instalados localmente en los Nodos del Cluster, que aleatoriamente tenían problemas de conexión a SQL Server, o bien problemas relacionados con Sockets. Básicamente, mostraban errores de conexión a SQL Server indicando que no se podían conectar a la instancia, como si la instancia no estuviese disponible, sin embargo todos los recursos de cada Grupo de Recursos de SQL, habían estado disponibles todo el tiempo, funcionando OK, y sin errores a nivel de SQL Server (ni el Application Log ni en el ERRORLOG).

El camino a la solución: NETSTAT, SQL Profiler y Data Collector

Entre las numerosas pruebas que tuve que hacer para obtener información de este problema, empecé a lanzar el comando NETSTAT –ano (re-direccionando la salida a un fichero, para poder comprobarlo después), en ambos Nodos del Cluster. Estuve haciendo esto durante multitud de ocasiones durante varios días. De aquí se obtuvo un dato importante: de forma aleatoria, se mostraban prácticamente todos los puertos de usuario (del 49000 al 65000 aprox en Win2008) ocupados para la dirección IP de cada Nodo del Cluster, la mayoría en estado TIME_WAIT, asociados al PID 0, y con destino la IP y puerto de la instancia de SQL Server.

De aquí, el siguiente paso relevante fue abrir una traza de SQL Server con el SQL Profiler, registrando únicamente los intentos de conexión y de desconexión a SQL Server. El resultado fue también muy interesante: prácticamente no había nada de actividad (de conexiones, quiero decir), y de pronto zas, miles de conexiones a SQL Server en un instante, cada conexión seguida de su desconexión, pero miles, todas ellas del SQL Server Agent y asociadas a la aplicación de Data Collector.

¿Podría ser que estas conexiones de los Jobs de Data Collector, que utilizan la identidad del SQL Server Agent, pudieran estar actuando como un ataque de denegación de servicio al agotar los puertos de usuario del Nodo del Cluster en el que se ejecutaba, dejándolos todos ocupados en estado TIME_WAIT durante un instante?

Nada mejor que usar el antiguo método prueba y error. Tras desactivar el Data Collector, y seguidamente desactivar los Jobs del Data Collector que aún seguían activos, fue cuestión de esperar, y voalá, tras varios días en observación, el problema quedó resuelto.

Alucinante. Así que, quería aprovechar para compartir con todos vosotros esta información, para quién le pueda resultar de interés.

Actualizado 26/07/2011. Hace pocos días me he enterado de que ya existe una KB de Microsoft que habla sobre este comportamiento y ofrece un FIX. En el caso de SQL Server 2008 R2 el FIX es montar el CU5. Por desgracia, con el CU6 el problema sigue ocurriendo (no he probado con CUs posteriores). La URL a dicha KB es la siguiente.

FIX: Upload jobs of data collector quickly open and close a large number of TCP ports if the jobs upload data to a MDW database in SQL Server 2008

Por otro lado, también he encontrado en otro Blog, información relacionada con este problema, en el cuál además se ofrece una solución alternativa (no la he probado). Aquí va la URL:

MDW Data Collection Upload may use up all available ports on a large server

Poco más por ahora. Si encuentro o averiguo algo interesante, intentaré actualizar este artículo.

 


[Fecha del Artículo (UTC): 27/06/2011]
[Autor: GuilleSQL]


Comentarios

mlucasg - 25/04/2012 (UTC)
Grande artigo!

Ajudou-me a localizar a causa do meu problema.

"Gracias"!


Marcelo



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