Équilibrage de charge

Article
02/27/2011

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. WCF peut 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, il n'existe pas de différence entre les applications WCF qui communiquent à l'aide de BasicHttpBinding et d'autres types courants 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="https://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 le sujet suivant les points de terminaison, les liaisons et les comportements par défaut, consultez Configuration simplifiée et Simplified Configuration for WCF Services.

É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é : pour ce faire, affectez false a la propriété EstablishSecurityContext de WSHttpBinding. Ou bien, si des sessions de sécurité sont requises, il est possible d'utiliser des sessions de sécurité avec état tel que décrit dans la rubrique « 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. Notez que 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.
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 de bail du canal et autres quotas de transport, consultez Quotas de transport.

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

Voir aussi

Concepts

Meilleures pratiques pour l'hébergement dans Internet Information Services

Partager via