Partager via

Équilibrage de la charge.

  • Article

L’une des méthodes utilisées pour augmenter la capacité des applications Windows Communication Foundation (WCF) consiste à les monter en charge en les déployant dans une batterie de serveurs à charge équilibrée. Les applications WCF peuvent faire l’objet d’un équilibrage de charge à l’aide des techniques d’équilibrage de charge standard, dont notamment les programmes d’équilibrage de charge logicielle tels Windows Network Load Balancing ainsi que les appareils d’équilibrage de charge matérielle.

Les sections suivantes traitent des considérations relatives à l’équilibrage de la charge des applications WCF construites à l’aide de diverses liaisons fournies par le système.

Équilibrage de charge avec la liaison HTTP de base

Du point de vue de l’équilibrage de charge, les applications WCF qui communiquent à l’aide de BasicHttpBinding sont identiques à celles d’autres types communs de trafic réseau HTTP (contenu HTML statique, pages ASP.NET ou services Web ASMX). Les canaux WCF qui utilisent cette liaison sont fondamentalement sans état et terminent leurs connexions lorsque le canal se ferme. C'est la raison pour laquelle BasicHttpBinding fonctionne bien avec les techniques d'équilibrage de charge HTTP existantes.

Par défaut, BasicHttpBinding envoie un en-tête HTTP de connexion dans les messages contenant une valeur Keep-Alive, ce qui permet aux clients d'établir des connexions persistantes aux services qui les prennent en charge. Cette configuration offre un débit supérieur car les connexions précédemment établies peuvent être réutilisées pour envoyer les messages suivants au même serveur. Toutefois, la réutilisation des connexions peut provoquer une forte association des clients à un serveur spécifique dans la batterie à charge équilibrée, ce qui réduit l'efficacité de l'équilibrage de charge tourniquet. Si vous ne souhaitez pas ce type de comportement, Keep-Alive HTTP peut être désactivé sur le serveur à l'aide de la propriété KeepAliveEnabled avec CustomBinding ou Binding défini par l'utilisateur. L'exemple suivant montre comment procéder à l'aide de la configuration :

<?xml version="1.0" encoding="utf-8" ?>  
<configuration>  
  
 <system.serviceModel>  
  <services>  
   <service
     name="Microsoft.ServiceModel.Samples.CalculatorService"  
     behaviorConfiguration="CalculatorServiceBehavior">  
     <host>  
      <baseAddresses>  
       <add baseAddress="http://localhost:8000/servicemodelsamples/service"/>  
      </baseAddresses>  
     </host>  
    <!-- configure http endpoint, use base address provided by host  
         And the customBinding -->  
     <endpoint address=""  
           binding="customBinding"  
           bindingConfiguration="HttpBinding"
           contract="Microsoft.ServiceModel.Samples.ICalculator" />  
   </service>  
  </services>  
  
  <bindings>  
    <customBinding>  
  
    <!-- Configure a CustomBinding that disables keepAliveEnabled-->  
      <binding name="HttpBinding" keepAliveEnabled="False"/>  
  
    </customBinding>  
  </bindings>  
 </system.serviceModel>  
</configuration>

À l’aide de la configuration simplifiée présentée dans .NET Framework 4, le même comportement peut être obtenu à l’aide de la configuration simplifiée suivante.

<?xml version="1.0" encoding="utf-8" ?>  
<configuration>  
 <system.serviceModel>  
    <protocolMapping>  
      <add scheme="http" binding="customBinding" />  
    </protocolMapping>  
    <bindings>  
      <customBinding>  
  
      <!-- Configure a CustomBinding that disables keepAliveEnabled-->  
        <binding keepAliveEnabled="False"/>  
  
      </customBinding>  
    </bindings>  
 </system.serviceModel>  
</configuration>

Pour plus d’informations sur les points de terminaison, les liaisons et les comportements par défaut, consultez Configuration simplifiée et Configuration simplifiée pour les services WCF.

Équilibrage de charge avec les liaisons WSHttp et WSDualHttp

WSHttpBinding et WSDualHttpBinding peuvent tous deux faire l’objet d’un équilibrage de charge à l’aide des techniques d’équilibrage de charge HTTP sous réserve que plusieurs modifications soient apportées à la configuration de liaison par défaut.

  • Désactivez l’établissement du contexte de sécurité ou utilisez des sessions de sécurité avec état. L’établissement du contexte de sécurité peut être désactivé en définissant la propriété EstablishSecurityContext sur le WSHttpBinding sur false. Si vous utilisez WSDualHttpBinding ou que des sessions de sécurité sont requises, il est possible d’utiliser des sessions de sécurité avec état, comme décrit dans Sessions sécurisées. Les sessions de sécurité avec état permettent au service de rester sans état car l’ensemble de l’état de la session de sécurité est transmis avec chaque demande dans le cadre du jeton de sécurité de protection. Pour activer une session de sécurité avec état, il est nécessaire d’utiliser CustomBinding ou Binding défini par l’utilisateur car les paramètres de configuration requis ne sont pas exposés sur WSHttpBinding et WSDualHttpBinding, qui sont fournis par le système.

  • Si vous désactivez l’établissement du contexte de sécurité, vous devez également désactiver la négociation des informations d’identification du service. Pour la désactiver, définissez la propriété NegotiateServiceCredential sur le WSHttpBinding sur false. Pour désactiver la négociation des informations d’identification du service, vous devrez peut-être spécifier explicitement l’identité du point de terminaison sur le client.

  • N'utilisez pas de session fiable. Cette fonctionnalité est désactivée par défaut.

Équilibrage de charge avec la liaison Net.TCP

NetTcpBinding peut faire l'objet d'un équilibrage de charge à l'aide des techniques d'équilibrage de charge au niveau de la couche IP. Cependant, NetTcpBinding regroupe les connexions TCP par défaut afin de réduire la latence de la connexion. Il s'agit d'une optimisation qui interfère avec le mécanisme de base d'équilibrage de charge. La valeur de configuration principale permettant d'optimiser NetTcpBinding est le délai de bail, qui fait partie des paramètres de pool de connexions. Le regroupement de connexions provoque l'association des connexions clientes à des serveurs spécifiques dans la batterie. Au fur et à mesure que la durée de vie de ces connexions augmente (facteur contrôlé par le paramètre de délai de bail), la distribution de la charge sur les divers serveurs dans la batterie est déséquilibrée. En conséquence, le temps d'appel moyen augmente. Donc lorsque vous utilisez NetTcpBinding dans les scénarios à charge équilibrée, réduisez le délai de bail par défaut utilisé par la liaison. Un délai de bail de 30 secondes est un point de départ raisonnable pour les scénarios à charge équilibrée, bien que la valeur optimale dépende de l'application. Pour plus d’informations sur le délai d’expiration de bail du canal et les autres quotas de transport, consultez la section Quotas de transport.

Pour de meilleures performances dans les scénarios à charge équilibrée, utilisez NetTcpSecurity (Transport ou TransportWithMessageCredential).

Voir aussi