Question Les serveurs sont soudainement incapables d'établir de nouvelles connexions; semble être un épuisement éphémère du port


Nous avons plusieurs serveurs Windows 2008R2 qui exécutent diverses applications commerciales (par exemple, SQL Server) et internes. Il s'agit d'une variété de ressources virtuelles et physiques, qui fonctionnent toutes sans problème depuis quelques années.

Cependant, au cours des dernières semaines, quelques serveurs ont soudainement cessé d’établir une nouvelle connexion réseau. Un exemple de cela est l'une de nos applications qui se connecte à SQL via une connexion socket normale - elle se bloque simplement. Essayer de naviguer sur un partage réseau de le serveur concerné nous dit

La limite de nom pour la carte réseau de l'ordinateur local a été dépassée

Pour moi, cela ressemblait à un bon épuisement du port éphémère à l'ancienne mode. Augmenter le nombre de ports éphémères résout temporairement le problème.

enter image description here

Cependant, même avec cela en place, le serveur ne dure que quelques jours avant que le problème ne se reproduise. De plus, je ne vois pas ce qui consomme un grand nombre de ports - encore une fois, rien a changé sur les serveurs et le problème est survenu sur 4 boîtes différentes exécutant différents types d’application.

Si je regarde le serveur le plus occupé, SQL Server 2014, TCPView affiche environ 1 000 connexions:

enter image description here

J'ai couru ce script qui enregistre l'utilisation des ports éphémères, et ne dépasse jamais quelques dizaines de ports.

Process Explorer ne montre rien d’excitant non plus:

enter image description here

Mon sentiment est que quelque chose dans le "patch mardi" de juillet a causé cela, mais je peux me tromper complètement. Tout ce que nous savons, c’est que les serveurs qui fonctionnaient auparavant ne fonctionnent plus après quelques jours, tout est mis à jour (en ce qui concerne les pilotes Microsoft et les pilotes du fournisseur), il affecte plusieurs serveurs, physiques et virtuels, et il n’ya aucun signe de gravure. par des ports éphémères. Quelqu'un peut-il suggérer comment isoler la cause des problèmes?


5
2017-08-16 08:12


origine


Pourriez-vous vérifier avec tcpview / netstat pour les connexions FIN_WAIT_2 et LAST_ACK? - Simone Zabberoni
Peur il n'y a aucun signe de connexions dans ces états - ils sont soit ESTABLISHED (la majorité) ou TIME_WAIT (seulement environ 20) - KenD
Utilisez-vous le -a option avec netstat pour afficher "toutes" les connexions? Recommande également d'utiliser -o pour l'ID de processus propriétaire, mais parfois, il s'agit de 0 pour les connexions orphelines. J'utilise généralement -ano - Clayton
Oui, j'utilise -ano. J'ai un serveur dans son état "problématique" pour le moment - c'est une heure avant la "fin de l'activité" et le moment où je peux le faire rebondir. netstat -ano rapports il y a 874 ESTABLISHED connexions, 17 TIME_WAIT connexions et 39 LISTENING. Si j'utilise netsh Pour augmenter la plage de ports éphémères, le problème disparaît - mais je n'ai plus de ports à allouer. - KenD


Réponses:


Vous pensez que la suspicion que la mise à jour de juillet est à l'origine du problème a du mérite. Essayez de désinstaller le correctif cumulatif du 11 juillet 2017 de l'un des serveurs concernés. Si le problème persiste, envisagez de contacter le support technique MS? Là encore, comme c'est un "problème connu" qui pourrait ne pas être très productif ...

Problèmes connus dans cette mise à jour KB4025341

Symptôme: En raison d'un défaut dans WLDAP32.DLL, les applications qui effectuent une recherche de renvoi LDAP peuvent consommer trop de ports TCP dynamiques (les épuiser potentiellement).

Solution de contournement: pour résoudre le problème, redémarrez les services ou les applications effectuant une référence LDAP en vue de libérer des ports dynamiques TCP.


4
2017-08-22 20:46



Intéressant. Le serveur a été redémarré il y a à peine une heure et à l'aide de Process Explorer, je peux voir les seules choses avec des descripteurs. WLDAP32.DLL sont Explorer et (bizarrement) l’application de mise à jour Java. Je me demande, si c'est ce problème, je m'attendrais à voir ces exécutables comme des "propriétaires" de connexions semi-ouvertes? Je vais attendre que le problème se reproduise (ce qui prend généralement quelques jours), puis essayer de bloquer et de supprimer cette mise à jour de ce serveur et de voir ce qui se passe. - KenD


Le script mentionné ici pourrait aider à diagnostiquer quel processus utilise les ports. Fondamentalement, il combine la sortie de netsh int ipv4 show dynamicportrange tcp avec netstat –ano –p tcp pour aider avec le diagnostic. Le texte mentionne également qu'il s'agit uniquement de rechercher des problèmes dans les processus en mode utilisateur, en expliquant comment WinDBG doit être utilisé pour diagnostiquer les problèmes dans les processus en mode noyau.

Ce fil mentionne également l'événement 4231 comme un autre indicateur du problème.


1
2017-08-24 18:10





Celui-ci est intéressant. J'ai attiré mon attention parce que j’avais précédemment rencontré des problèmes lors de l’ouverture de plusieurs connexions TCP avec des serveurs Windows. Enregistrez-vous la CPU, le débit du réseau et remarquez-vous des anomalies?

En supposant que vous faites post mortem, vous avez probablement vérifié les journaux et n'avez rien remarqué d'inhabituel. Le trafic est-il à la hausse? Tout ce qui pourrait expliquer la hausse des erreurs. Les 4 cases sont-elles sur le même sous-réseau? Accédé par différentes applications?

Autres choses à regarder, les connexions partagées. La gamme étendue de ports éphémères était-elle ouverte lors de la création d'actions?

Connexions TCP TCB. Je pense que son 2000 sur 2k8 R2. Vérifiez bien cela. Bonne chance avec celui-ci.


0
2017-08-22 16:39



Il n'y a aucun signe d'anomalie sur le serveur - la CPU, la mémoire et le réseau sont tous assez standards. Une fois que le problème est survenu, il restera comme ça jusqu'à ce que je redémarre le serveur - même lorsqu'il n'y a aucune activité de l'utilisateur et que le serveur est très "silencieux". Il n'y a que 2 actions, toutes deux créées il y a des années, bien avant que ce problème ne survienne. - KenD