WCF derrière l'équilibreur de charge - comment configurer

Question

Nous avons deux serveurs Web utilisant l'équilibreur de charge. Les machines exécutent IIS6 sur le port 81. En externe, le site est accessible via le port 80. Le nom externe et le nom de la machine sont différents.

Nous recevons

System.ServiceModel.EndpointNotFoundException: The message with To '<url>' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree. 

Partie pertinente du web.config est:

<endpoint binding="ws2007HttpBinding" bindingConfiguration="MyServiceBinding" 
    contract="MyService.IMyService" listenUriMode="Explicit" /> 

Nous avons essayé d'ajouter listenUri, mais cela ne résout pas nos problèmes.

Des idées?

Answer 1

[ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)] 

La mise en service de cet attribut résout le problème.

Answer 2

Qu'est-ce que l'équilibreur de charge spécifique? En utilisant un BIG-IP F5, nous l'avons fait assez facilement, mais nous utilisions le même port et l'uri (relatif) sur le nlb que des machines individuelles (ainsi nous pouvons traiter une machine individuelle comme la ferme si nous choisissons). Évidemment, chaque machine a un nom différent, mais cette configuration vous permet également de tester des serveurs individuels en usurpant l'hôte - par exemple, en éditant votre fichier HOSTS pour pointer [votre nom de ferme] sur [tester l'adresse IP du serveur].

La plus grande douleur que nous avions était SSL; En utilisant la sécurité TransportWithMessageCredential, WCF refuse les connexions http entrantes - nous avons donc dû configurer le nlb pour rechiffrer entre le nlb et le nœud du serveur - mais pas un biggie. Le seul autre problème que nous avons eu était d'héberger WCF dans IIS, et WCF ne pouvait pas identifier correctement le site prévu (bien que IIS soit correct) sur http (mais bien sur https). Pour résoudre ce problème, j'ai écrit une fabrique personnalisée qui ignorait tout simplement complètement le protocole http (seulement écouté sur https) - ce qui, de toute façon, correspond parfaitement aux exigences de TransportWithMessageCredential, ce qui ne me dérangeait pas.

Je me demande si vous n'obtiendrez pas plus de joie en hébergeant sur un port standard mais en tant que site différent (IP/host-header/etc).