Excepciones esporádicas al llamar a un servicio web con equilibrio de carga

Question

Tengo un servicio web que estoy ejecutando en tres servidores web con equilibrio de carga y recibo errores esporádicos. Ahora, admito que la parte de carga balanceada puede ser una pista falsa, pero cuando pruebo con solo 1 servidor web no puedo reproducir el error. Si pruebo con los tres servidores web, puedo obtener el error (pero no es el 100% del tiempo, más como el 50%). Todas las pruebas se realizan a través del equilibrador de carga, solo le informamos al equilibrador de carga cuántos servidores queremos explotar.

El código es simple código de solicitud individual. Es decir, no hay estado. Se realiza una solicitud y se devuelve una respuesta. El código del servicio web es C# .NET 4 ejecutándose en IIS 7.5. El código del cliente es tanto un sitio web como una aplicación de escritorio.

consigo una de las dos excepciones:

System.ServiceModel.Security.MessageSecurityException: Un no garantizada o asegurada de forma incorrecta culpa fue recibida de la otra parte . Consulte la FaultException interna para conocer el código de error y los detalles. ---> System.ServiceModel.FaultException: El token de contexto de seguridad ha expirado o no es válido. El mensaje no se procesó .

O me sale:

System.ServiceModel.Security.SecurityNegotiationException: Canal seguro no se puede abrir porque negociación de seguridad con el extremo remoto ha fallado. Esto puede se debe a ausente o incorrectamente EndpointIdentity especificado en EndpointAddress utilizado para crear el canal . Verifique que EndpointIdentity especificado o implícito por EndpointAddress correctamente identifica el punto final remoto. ---> System.ServiceModel.FaultException: La solicitud de token de seguridad tiene elementos no válidos o mal formados.

Como puede ver en los siguientes snips de mis archivos .config, no estoy utilizando la seguridad ya que este es estrictamente un servicio web interno. (los nombres han sido cambiados para proteger a los inocentes, es decir, a mí).

el lado del servidor:

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
<!-- Service Side web.config --> 
... 
    <system.serviceModel> 
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> 
    <services> 
     <service behaviorConfiguration="InternalUseOnly.InternalUseOnlyServiceBehavior" name="InternalUseOnly.InternalUseOnlyService"> 
     <endpoint address="" bindingNamespace="http://somecompany.com/webservices" binding="wsHttpBinding" contract="InternalUseOnly.IInternalUseOnlyService"> 
      <identity> 
      <dns value="localhost" /> 
      </identity> 
     </endpoint> 
     <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> 
     </service> 
    </services> 
    <behaviors> 
     <serviceBehaviors> 
     <behavior name="InternalUseOnly.InternalUseOnlyServiceBehavior"> 
      <serviceMetadata httpGetEnabled="true" /> 
      <serviceDebug includeExceptionDetailInFaults="true" /> 
     </behavior> 
     </serviceBehaviors> 
    </behaviors> 
    </system.serviceModel> 
... 
</configuration> 

lado del cliente

<?xml version="1.0" encoding="UTF-8"?> 
<!-- Client Side web.config --> 
<configuration> 
... 
    <system.serviceModel> 
     <bindings> 
     <wsHttpBinding> 
      <binding name="WSHttpBinding_IInternalUseOnlyService" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" allowCookies="false"> 
      <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 
      <reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="false" /> 
      <security mode="Message"> 
       <transport clientCredentialType="Windows" proxyCredentialType="None" realm="" /> 
       <message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" /> 
      </security> 
      </binding> 
     </wsHttpBinding> 
     </bindings> 
     <client> 
     <endpoint address="http://intranet.somecompany.com/InternalUseOnly/InternalUseOnlyService.svc" binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IInternalUseOnlyService" contract="InternalUseOnlyService.IInternalUseOnlyService" name="WSHttpBinding_IInternalUseOnlyService"> 
      <identity> 
      <dns value="localhost" /> 
      </identity> 
     </endpoint> 
     </client> 
    </system.serviceModel> 
... 
</configuration> 

Pensamientos alguien?

---

Información adicional: Después de revisar las respuestas a continuación he intentado dos cosas, ambas sin éxito.

El cambio más obvio (que no noté al principio) fue cambiar una de las propiedades en el cliente para permitir las cookies <system.serviceModel><bindings><wsHttpBinding><binding name="blah, blah, blah" ... other properties... allowCookies="true" /> Por defecto es falso. Además, nuestro equilibrador de carga usa cookies para mantener la afinidad. Pero, no marcó la diferencia (aún no se sabe por qué).

A continuación, probé varias opciones de seguridad en el archivo app.config del lado del cliente. Esto incluye tanto <security mode="None" /> y una más elaborada:

<security mode="None"> 
    <transport clientCredentialType="None" proxyCredentialType="None" /> 
    <message clientCredentialType="None" establishSecurityContext="false" negotiateServiceCredential="false"/> 
</security> 

a pesar de los ajustes en el último fue sólo una conjetura de mi parte. No realicé ningún cambio en el servidor de la aplicación.config ya que no sé qué cambiar y, por desgracia, solo puedo probar con la producción ya que solo tenemos 1 servidor web de desarrollo, no tres.

Answer 1

Mientras que Chris y Jeff me ayudaron a encontrar una respuesta, lo que en realidad me solucionó fue este artículo que encontré de Microsoft en Load Balancing Web Services. En resumen, lo que tuvimos que hacer para resolver esto en nuestra granja de servidores web fue cambiar el valor predeterminado de wsHttpBinding a basicHttpBinding. Esto no fue difícil, pero fue un movimiento de todo o nada. El servicio web principal y cada cliente tenían que reconfigurarse al mismo tiempo o se rompería.

Mientras wsHttpBinding tiene una propiedad de allowCooikes que podría tener el valor true, que aparentemente no usarlos hasta después de realizada la conexión, momento en el que la solicitud podría saltar servidores en la primera solicitud y por lo tanto fallar.

Answer 2

Es un problema NTLM causado por el uso de equilibradores de carga sin sesiones adhesivas. Para corregir el problema, debe configurar la afinidad de sesión (sesión adhesiva). Si no lo hace, obtendrá un error porque parte del intercambio de información de NTLM ocurrió en un servidor y la otra parte en otro servidor.

Answer 3

Voy a salir a un miembro aquí y supongo que la garantía sea la seguridad de mensaje especificado en el lado del cliente:

<security mode="Message"> 
    <transport clientCredentialType="Windows" proxyCredentialType="None" realm="" /> 
    <message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" /> 
</security> 

Si va a crear un cliente y la conexión, el negociado de credenciales de Windows token puede ser almacenado en caché. Si no tiene habilitadas las sesiones adhesivas, es posible que el token se devuelva al servidor incorrecto y falle. ¿Supongo que siempre está en la segunda llamada?