Partager via

Configuration requise pour l’équilibrage de charge pour Skype Entreprise

  • Article

Résumé: Passez en revue les considérations relatives à l’équilibrage de charge avant d’implémenter Skype Entreprise Server.

L’équilibrage de charge répartit le trafic entre les serveurs d’un pool. Si vous avez des pools frontaux, des pools de serveurs de médiation ou des pools de serveurs Edge, vous devez déployer l’équilibrage de charge pour ces pools.

Skype Entreprise Server prend en charge deux types de solutions d’équilibrage de charge pour le trafic client-serveur : l’équilibrage de charge DNS (Domain Name System) et l’équilibrage de charge matérielle (souvent abrégé en HLB). L’équilibrage de charge DNS offre plusieurs avantages, notamment une administration plus simple, une résolution des problèmes plus efficace et la possibilité d’isoler une grande partie de votre trafic Skype Entreprise Server de tout problème potentiel d’équilibreur de charge matérielle.

Déterminez vous-même la solution d’équilibrage de charge appropriée pour chaque pool de votre déploiement, mais gardez à l’esprit les restrictions suivantes :

  • Les interfaces Edge interne et externe doivent utiliser le même type d’équilibrage de charge. Vous ne pouvez pas utiliser l’équilibrage de charge DNS sur une interface et l’équilibrage de charge matérielle sur l’autre.

  • Certains types de trafic nécessitent un programme dʼéquilibrage de charge matérielle. Par exemple, le trafic HTTP requiert un équilibrage de charge matérielle plutôt que l’équilibrage de charge DNS. Celui-ci ne fonctionne pas avec le trafic web client à serveur.

Si vous décidez d’utiliser l’équilibrage de la charge DNS pour un pool mais que vous souhaitez quand même implémenter des équilibreurs de la charge matérielle pour certains types de trafics, tels que le trafic HTTP, l’administration des équilibreurs de la charge matérielle est grandement simplifiée. Par exemple, l’équilibreur de charge matérielle sera plus simple car il ne gérera que le trafic HTTP et HTTPS, alors que tous les autres protocoles seront gérés par l’équilibrage de charge DNS. Pour plus d’informations, voir DNS Load Balancing.

Pour le trafic de serveur à serveur, Skype Entreprise Server utilise l’équilibrage de charge prenant en charge la topologie. Les serveurs lisent la topologie publiée dans le magasin central de gestion pour obtenir les noms de domaine complets des serveurs dans la topologie et répartir automatiquement le trafic entre les serveurs. Les administrateurs n’ont pas besoin de configurer ou de gérer ce type d’équilibrage de charge.

Si vous utilisez l’équilibrage de charge DNS et que vous devez bloquer le trafic vers un ordinateur spécifique, il ne suffit pas de supprimer simplement les entrées d’adresse IP du nom de domaine complet du pool. Vous devez également supprimer l’entrée DNS de l’ordinateur.

Configuration requise pour l’équilibreur de charge matérielle

La topologie Edge consolidée Skype Entreprise Server mise à l’échelle est optimisée pour l’équilibrage de charge DNS pour les nouveaux déploiements fédérant principalement avec d’autres organisations utilisant Skype Entreprise Server ou Lync Server. Si la haute disponibilité est requise pour l’un des scénarios suivants, un équilibreur de charge matériel doit être utilisé sur les pools de serveurs Edge pour les éléments suivants :

  • Fédération avec des organisations utilisant Office Communications Server 2007 R2 ou Office Communications Server 2007

  • Messagerie unifiée Exchange pour les utilisateurs distants utilisant la messagerie unifiée Exchange avant Exchange 2010 avec SP1

  • Connectivité avec les utilisateurs de messagerie instantanée publique

Important

L’utilisation de l’équilibrage de charge DNS sur une interface et de l’équilibrage de charge matérielle sur l’autre n’est pas prise en charge. Sur les deux interfaces, vous devez utiliser l’équilibrage de charge matérielle ou l’équilibrage de charge DNS.

Remarque

Si vous utilisez un équilibreur de charge matériel, l’équilibreur de charge déployé pour les connexions avec le réseau interne doit être configuré pour équilibrer la charge uniquement le trafic vers les serveurs exécutant le service Edge Access et le service Edge A/V. Il ne peut pas équilibrer la charge du trafic vers le service Edge de conférence web interne ou le service proxy XMPP interne.

Remarque

Le nat de retour direct du serveur (DSR) n’est pas pris en charge avec Skype Entreprise Server.

Pour déterminer si votre équilibreur de charge matériel prend en charge les fonctionnalités nécessaires requises par Skype Entreprise Server, consultez Infrastructure pour Skype Entreprise.

Configuration requise pour l’équilibreur de la charge matérielle des serveurs Edge exécutant le service Edge A/V

Voici la configuration requise de l’équilibreur de charge matériel pour les serveurs Edge exécutant le service Edge A/V :

  • Désactivez le nagling TCP pour les ports 443 interne et externe. Le nagling est le processus qui consiste à combiner plusieurs petits paquets en un seul paquet plus volumineux afin de rendre la transmission plus efficace.

  • Désactivez le nagling TCP pour la plage de ports externes comprise entre 50 000 et 59 999.

  • N’utilisez pas NAT sur le pare-feu interne ou externe.

  • L’interface interne de périphérie doit se trouver sur un réseau différent de l’interface externe du serveur Edge et le routage entre eux doit être désactivé.

  • L’interface externe du serveur Edge exécutant le service Edge A/V doit utiliser des adresses IP routables publiquement et aucune traduction nat ou port sur l’une des adresses IP externes de périphérie.

  • L’équilibreur de la charge ne doit pas modifier lʼadresse source du client.

Autres exigences matérielles Load Balancer

Les exigences d’affinité basée sur les cookies sont considérablement réduites dans Skype Entreprise Server pour les services Web. Si vous déployez Skype Entreprise Server et que vous ne conservez pas de serveurs frontaux Lync Server 2010 ou de pools frontaux, vous n’avez pas besoin de persistance basée sur les cookies. Toutefois, si vous souhaitez conserver temporairement ou définitivement des serveurs frontaux Lync Server 2010 ou des pools frontaux, vous utilisez toujours la persistance basée sur les cookies lorsqu’elle est déployée et configurée pour Lync Server 2010.

Remarque

Si vous décidez d’utiliser l’affinité basée sur les cookies même si votre déploiement n’en a pas besoin, aucun impact négatif n’en résultera.

Pour les déploiements qui nʼutiliseront pas lʼaffinité basée sur les cookies :

  • Dans la règle de publication de proxy inverse pour le port 4443, définissez l’en-tête de l’hôte Forward sur True. Cela garantit que l’URL d’origine est transférée.

Pour des déploiements qui utiliseront lʼaffinité basée sur les cookies :

  • Dans la règle de publication de proxy inverse pour le port 4443, définissez l’en-tête de l’hôte Forward sur True. Cela garantit que l’URL d’origine est transférée.

  • Le cookie de l’équilibreur de la charge matérielle NE DOIT PAS être marqué httpOnly

  • Le cookie de l’équilibreur de la charge matérielle NE DOIT PAS inclure d’heure d’expiration

  • Le cookie de l’équilibreur de la charge matérielle DOIT être nommé MS-WSMAN (Il s’agit de la valeur attendue par les services web et elle ne peut pas être modifiée)

  • Le cookie de l’équilibreur de la charge matérielle DOIT être défini dans chaque réponse HTTP pour laquelle la requête HTTP entrante ne possédait pas de cookie, qu’une réponse HTTP précédente ait déjà obtenu ou non un cookie sur cette même connexion TCP. Si l’équilibreur de la charge optimise l’insertion de cookies afin qu’elle se produise une seule fois par connexion TCP, cette optimisation NE DOIT PAS être utilisée

Remarque

Les configurations d’équilibreur de charge matérielle classiques utilisent l’affinité source-adresse et une durée de 20 minutes. Durée de vie de session TCP, qui convient pour les clients Lync Server et Lync 2013, car l’état de session est conservé via l’utilisation du client et/ou l’interaction de l’application.

Si vous déployez des appareils mobiles, votre équilibreur de la charge matérielle doit être capable d’équilibrer la charge d’une requête individuelle au sein d’une session TCP (en effet, vous devez être en mesure d’équilibrer la charge d’une requête individuelle en fonction de l’adresse IP cible).

Attention

Si vous déployez des appareils mobiles, votre équilibreur de charge matériel doit être en mesure d’équilibrer la charge individuellement chaque requête au sein d’une connexion TCP. Les dernières applications pour mobile iOS d’Apple requièrent la version 1.2 de TLS (Transport Layer Security).

Attention

Pour plus d’informations sur les équilibreurs de charge matériels tiers, consultez Infrastructure pour Skype Entreprise.

La configuration requise de l’équilibreur de la charge matérielle des services web du directeur et du pool de serveurs frontaux est la suivante :

  • Pour les adresses IP virtuelles (VIP) des services web internes, définissez la persistance Source_addr (port interne 80, 443) sur l’équilibreur de la charge matérielle. Par Skype Entreprise Server, Source_addr persistance signifie que plusieurs connexions provenant d’une seule adresse IP sont toujours envoyées à un serveur pour conserver l’état de session.

  • Utilisez un délai d’inactivité TCP de 1 800 secondes.

  • Sur le pare-feu entre le proxy inverse et l’équilibreur de charge matérielle du pool de tronçons suivants, créez une règle pour autoriser le trafic https: sur le port 4443, du proxy inverse à l’équilibreur de charge matérielle. L’équilibreur de la charge matérielle doit être configuré pour écouter sur les ports 80, 443 et 4443.

Synthèse des conditions requises en termes d’affinité pour l’équilibreur de la charge matérielle

Emplacement du client/de l’utilisateur Conditions requises en matière d’affinité pour le nom de domaine complet des services web externes Conditions requises en matière d’affinité pour le nom de domaine complet des services web internes
Lync Web App (utilisateurs internes et externes)
Appareil mobile (utilisateurs internes et externes)
 Aucune affinité
 Affinité des adresses sources
Lync Web App (utilisateurs externes uniquement)
Appareil mobile (utilisateurs internes et externes)
 Aucune affinité
 Affinité des adresses sources
Lync Web App (utilisateurs internes uniquement)
Appareil mobile (non déployé)
 Aucune affinité
 Affinité des adresses sources

Surveillance des ports pour les programmes d’équilibrage de la charge matérielle

Vous définissez la surveillance des ports sur les équilibreurs de la charge matérielle pour déterminer si des services spécifiques ne sont plus disponibles suite à des échecs matériel ou de communication. Par exemple, si le service serveur frontal (RTCSRV) s’arrête en raison de l’échec du serveur frontal ou du pool frontal, l’analyse HLB doit également cesser de recevoir le trafic sur les services web. Vous implémentez la surveillance des ports sur le programme d’équilibrage de la charge matérielle pour surveiller les éléments suivants :

Pool d’utilisateurs du serveur frontal - Interface interne HLB

IP/Port virtuel Port de nœud Nœud Ordinateur/Écran Profil de persistance Notes
<pool>web-int_mco_443_vs
443
 443
 Serveur frontal
5061
 Source
 HTTPS
<pool>web-int_mco_80_vs
80
 80
 Serveur frontal
5061
 Source
 HTTP

Pool d’utilisateurs de serveur frontal - Interface externe HLB

IP/Port virtuel Port de nœud Nœud Ordinateur/Écran Profil de persistance Notes
<pool>web_mco_443_vs
443
 4443
 Serveur frontal
5061
 Aucune
 HTTPS
<web_mco_80_vs de pool>
80
 8080
 Serveur frontal
5061
 Aucune
 HTTP

DNS Load Balancing

Skype Entreprise Server permet l’équilibrage de charge DNS, une solution logicielle qui peut réduire considérablement la surcharge d’administration pour l’équilibrage de charge sur votre réseau. L’équilibrage de charge DNS équilibre le trafic réseau propre aux Skype Entreprise Server, comme le trafic SIP et le trafic multimédia.

Si vous déployez l’équilibrage de charge DNS, la surcharge d’administration de votre organization pour les équilibreurs de charge matériels sera réduite. En outre, la résolution des problèmes complexes liés à une mauvaise configuration des équilibreurs de charge pour le trafic SIP sera éliminée. Vous pouvez également empêcher les connexions de serveur afin de pouvoir mettre les serveurs hors connexion. L’équilibrage de charge DNS garantit également que les problèmes d’équilibreur de charge matériel n’affectent pas les éléments du trafic SIP tels que le routage des appels de base.

Le diagramme suivant illustre un exemple qui inclut l’équilibrage de charge DNS interne et externe :

Diagramme réseau Edge utilisant des adresses IPv4 publiques

exemple de diagramme de réseau DNS.

Si vous utilisez l’équilibrage de charge DNS, vous pouvez également acheter des équilibreurs de charge matériels à moindre coût que si vous utilisiez les équilibreurs de charge matériels pour tous les types de trafic. Vous devez utiliser des équilibreurs de charge qui ont passé des tests de qualification d’interopérabilité avec Skype Entreprise Server. Pour plus d’informations sur les tests d’interopérabilité de l’équilibreur de charge, consultez Lync Server 2010 Load Balancer Partenaires. Le contenu s’applique à Skype Entreprise Server.

L’équilibrage de charge DNS est pris en charge pour les pools frontaux, les pools de serveurs Edge, les pools de directeurs et les pools de serveurs de médiation autonomes.

L’équilibrage de charge DNS est généralement implémenté au niveau de l’application. L’application (par exemple, un client exécutant Skype Entreprise) tente de se connecter à un serveur dans un pool en se connectant à l’une des adresses IP retournées par la requête d’enregistrement DNS A et AAAA (si l’adressage IPv6 est utilisé) pour le nom de domaine complet (FQDN) du pool.

Par exemple, s’il existe trois serveurs frontaux dans un pool nommé pool01.contoso.com, les opérations suivantes se produisent :

  • Les clients exécutant Skype Entreprise interrogent dns pour pool01.contoso.com. La requête retourne trois adresses IP et les met en cache comme suit (pas nécessairement dans cet ordre) :

    pool01.contoso.com 192.168.10.90

    pool01.contoso.com 192.168.10.91

    pool01.contoso.com 192.168.10.92

  • Le client tente d’établir une connexion TCP (Transmission Control Protocol) à l’une des adresses IP. En cas d’échec, le client tente l’adresse IP suivante dans le cache.

  • Si la connexion TCP aboutit, le client négocie le protocole TLS pour se connecter au serveur d’inscriptions principal sur pool1.contoso.com.

  • Si le client tente toutes les entrées mises en cache sans connexion réussie, l’utilisateur est averti qu’aucun serveur exécutant Skype Entreprise Server n’est disponible pour le moment.

Remarque

L’équilibrage de charge dns est différent du tourniquet DNS (DNS RR) qui fait généralement référence à l’équilibrage de charge en s’appuyant sur DNS pour fournir un ordre différent d’adresses IP correspondant aux serveurs d’un pool. En règle générale, DNS RR active uniquement la distribution de la charge, mais n’active pas le basculement. Par exemple, si la connexion à l’adresse IP retournée par la requête DNS A et AAAA (si vous utilisez l’adressage IPv6) échoue, la connexion échoue. Par conséquent, le tourniquet DNS en lui-même est moins fiable que l’équilibrage de charge basé sur DNS. Vous pouvez utiliser le tourniquet DNS conjointement avec l’équilibrage de charge DNS.

L’équilibrage de charge DNS est utilisé pour les éléments suivants :

  • Équilibrage de charge sip de serveur à serveur sur les serveurs Edge

  • Applications UCAS (Unified Communications Application Services) d’équilibrage de charge, telles que le standard automatique de conférence, response group et le parcage d’appels

  • Prévention des nouvelles connexions aux applications UCAS (également appelées « drainage »)

  • Équilibrage de charge de tout le trafic client à serveur entre les clients et les serveurs Edge

L’équilibrage de charge DNS ne peut pas être utilisé pour les éléments suivants :

  • Trafic web de client à serveur vers les serveurs directeurs ou frontaux

Équilibrage de charge DNS et trafic fédéré :

Si plusieurs enregistrements DNS sont retournés par une requête SRV DNS, le service Edge d’accès sélectionne toujours l’enregistrement SRV DNS avec la priorité numérique la plus basse et la pondération numérique la plus élevée. Le document Internet Engineering Task Force « A DNS RR for specifying the location of services (DNS SRV) » RFC 2782, DNS SRV RR spécifie que si plusieurs enregistrements SRV DNS sont définis, la priorité est d’abord utilisée, puis la pondération. Par exemple, l’enregistrement DNS SRV A a un poids de 20 et une priorité de 40, et l’enregistrement SRV DNS B a un poids de 10 et une priorité de 50. L’enregistrement DNS SRV A de priorité 40 est sélectionné. Les règles suivantes s’appliquent à la sélection d’enregistrements DNS SRV :

  • La priorité est considérée en premier. Un client DOIT tenter de contacter l’hôte cible défini par l’enregistrement SRV DNS avec la priorité numérotée la plus basse qu’il peut atteindre. Les cibles ayant la même priorité DOIVENT être essayées dans un ordre défini par le champ de pondération.

  • Le champ weight spécifie une pondération relative pour les entrées ayant la même priorité. Les pondérations supérieures DEVRAIENT être proportionnellement plus susceptibles d’être sélectionnées. Les administrateurs DNS DOIVENT utiliser Weight 0 lorsqu’il n’y a pas de sélection de serveur à effectuer. En présence d’enregistrements contenant des poids supérieurs à 0, les enregistrements de poids 0 doivent avoir une très petite chance d’être sélectionnés.

Si plusieurs enregistrements SRV DNS avec une priorité et une pondération égales sont retournés, le service Edge d’accès sélectionne l’enregistrement SRV reçu en premier du serveur DNS.

Équilibrage de charge DNS sur les pools frontaux et les pools de directeurs

Vous pouvez utiliser l’équilibrage de charge DNS pour le trafic SIP sur les pools frontaux et les pools de directeurs. Avec l’équilibrage de charge DNS déployé, vous devez toujours utiliser également des équilibreurs de charge matériels pour ces pools, mais uniquement pour le trafic HTTPS client-serveur. L’équilibreur de charge matériel est utilisé pour le trafic HTTPS provenant des clients sur les ports 443 et 80.

Bien que vous ayez toujours besoin d’équilibreurs de charge matériels pour ces pools, leur configuration et leur administration seront principalement destinées au trafic HTTPS, auquel les administrateurs d’équilibreurs de charge matériels sont habitués.

Équilibrage de charge DNS et prise en charge des clients et serveurs plus anciens

L’équilibrage de charge DNS prend en charge le basculement automatique uniquement pour les serveurs exécutant Skype Entreprise Server ou Lync Server 2010, ainsi que pour les clients Lync 2013 et Skype Entreprise. Les versions antérieures des clients et d’Office Communications Server peuvent toujours se connecter à des pools exécutant l’équilibrage de charge DNS, mais s’ils ne peuvent pas établir de connexion au premier serveur auquel l’équilibrage de charge DNS fait référence, ils ne peuvent pas basculer vers un autre serveur du pool.

En outre, si vous utilisez la messagerie unifiée Exchange, vous devez utiliser au moins Exchange 2010 SP1 pour obtenir la prise en charge de Skype Entreprise Server l’équilibrage de charge DNS. Si vous utilisez une version antérieure d’Exchange, vos utilisateurs n’auront pas de fonctionnalités de basculement pour ces scénarios de messagerie unifiée Exchange :

  • Lecture de leur messagerie vocale d’entreprise sur leur téléphone

  • Transfert d’appels à partir d’un standard automatique de messagerie unifiée Exchange

Tous les autres scénarios de messagerie unifiée Exchange fonctionnent correctement.

Déploiement de l’équilibrage de charge DNS sur les pools frontaux et les pools de directeurs

Le déploiement de l’équilibrage de charge DNS sur des pools frontaux et des pools de directeurs vous oblige à effectuer quelques étapes supplémentaires avec les noms de domaine complets et les enregistrements DNS.

  • Un pool qui utilise l’équilibrage de charge DNS doit avoir deux noms de domaine complets : le nom de domaine complet du pool normal utilisé par l’équilibrage de charge DNS (par exemple, pool01.contoso.com) et qui est résolu en adresses IP physiques des serveurs dans le pool, et un autre nom de domaine complet pour les services Web du pool (tels que web01.contoso.com), qui est résolu en adresse IP virtuelle du pool.

    Dans le Générateur de topologie, si vous souhaitez déployer l’équilibrage de charge DNS pour un pool, pour créer ce nom de domaine complet supplémentaire pour les services Web du pool, vous devez sélectionner la zone de case activée remplacer le nom de domaine complet du pool de services Web internes et taper le nom de domaine complet, dans la page Spécifier les URL des services web pour ce pool.

  • Pour prendre en charge le nom de domaine complet utilisé par l’équilibrage de charge DNS, vous devez provisionner dns pour résoudre le nom de domaine complet du pool (par exemple, pool01.contoso.com) en adresses IP de tous les serveurs du pool (par exemple, 192.168.1.1, 192.168.1.2, etc.). Vous devez inclure uniquement les adresses IP des serveurs actuellement déployés.

    Attention

    Si vous avez plusieurs pools frontaux ou serveurs frontaux, le nom de domaine complet des services Web externes doit être unique. Par exemple, si vous définissez le nom de domaine complet des services Web externes d’un serveur frontal comme pool01.contoso.com, vous ne pouvez pas utiliser pool01.contoso.com pour un autre pool frontal ou serveur frontal. Si vous déployez également des directeurs, le nom de domaine complet des services Web externes défini pour tout pool de directeurs ou de directeurs doit être unique à partir de tout autre pool de directeurs ou de directeurs, ainsi que de tout pool frontal ou serveur frontal. Si vous décidez de remplacer les services web internes par un nom de domaine complet autodéfini, chaque nom de domaine complet doit être unique de tout autre pool frontal, directeur ou pool de directeurs.

Équilibrage de charge DNS sur les pools de serveurs Edge

Vous pouvez déployer l’équilibrage de charge DNS sur des pools de serveurs Edge. Si c’est le cas, vous devez être conscient de certaines considérations.

L’utilisation de l’équilibrage de charge DNS sur vos serveurs Edge entraîne une perte de capacité de basculement dans les scénarios suivants :

  • La fédération avec les organisations qui exécutent des versions de Skype Entreprise Server publiées avant Lync Server 2010.

  • Échange de messages instantanés avec les utilisateurs des services de messagerie instantanée publics AOL et Yahoo!, en plus des fournisseurs et serveurs XMPP, tels que Google Talk, actuellement le seul partenaire XMPP pris en charge.

Ces scénarios fonctionnent tant que tous les serveurs Edge du pool sont opérationnels, mais si un serveur Edge n’est pas disponible, toutes les demandes de ces scénarios qui lui sont envoyées échouent, au lieu d’être acheminées vers un autre serveur Edge.

Si vous utilisez la messagerie unifiée Exchange, vous devez utiliser au minimum Exchange 2013 pour obtenir la prise en charge de Skype Entreprise Server équilibrage de charge DNS sur Edge. Si vous utilisez une version antérieure d’Exchange, vos utilisateurs distants n’auront pas de fonctionnalités de basculement pour ces scénarios de messagerie unifiée Exchange :

  • Lecture de leur messagerie vocale d’entreprise sur leur téléphone

  • Transfert d’appels à partir d’un standard automatique de messagerie unifiée Exchange

Tous les autres scénarios de messagerie unifiée Exchange fonctionnent correctement.

Les interfaces Edge interne et externe doivent utiliser le même type d’équilibrage de charge. Vous ne pouvez pas utiliser l’équilibrage de la charge DNS sur une interface Edge et l’équilibrage de la charge matérielle sur l’autre interface Edge.

Déploiement de l’équilibrage de charge DNS sur des pools de serveurs Edge

Pour déployer l’équilibrage de charge DNS sur l’interface externe de votre pool de serveurs Edge, vous avez besoin des entrées DNS suivantes :

  • Pour le service Edge d’accès, vous avez besoin d’une entrée pour chaque serveur du pool. Chaque entrée doit résoudre le nom de domaine complet du service Edge d’accès (par exemple, sip.contoso.com) en adresse IP du service Edge d’accès sur l’un des serveurs Edge du pool.

  • Pour le service Edge de conférence web, vous avez besoin d’une entrée pour chaque serveur du pool. Chaque entrée doit résoudre le nom de domaine complet du service Edge de conférence web (par exemple, webconf.contoso.com) en adresse IP du service Edge de conférence web sur l’un des serveurs Edge du pool.

  • Pour le service Edge audio/vidéo, vous avez besoin d’une entrée pour chaque serveur du pool. Chaque entrée doit résoudre le nom de domaine complet du service Edge audio/vidéo (par exemple, av.contoso.com) en adresse IP du service Edge A/V sur l’un des serveurs Edge du pool.

Pour déployer l’équilibrage de charge DNS sur l’interface interne de votre pool de serveurs Edge, vous devez ajouter un enregistrement DNS A, qui résout le nom de domaine complet interne du pool de serveurs Edge à l’adresse IP de chaque serveur du pool.

Utilisation de l’équilibrage de charge DNS sur les pools de serveurs de médiation

Vous pouvez utiliser l’équilibrage de charge DNS sur des pools de serveurs de médiation autonomes. L’ensemble du trafic SIP et du trafic multimédia est équilibré par l’équilibrage de charge DNS.

Pour déployer l’équilibrage de charge DNS sur un pool de serveurs de médiation, vous devez provisionner dns pour résoudre le nom de domaine complet du pool (par exemple, mediationpool1.contoso.com) sur les adresses IP de tous les serveurs du pool (par exemple, 192.168.1.1, 192.168.1.2, etc.).

Blocage du trafic vers un serveur avec l’équilibrage de charge DNS

Si vous utilisez l’équilibrage de charge DNS et que vous devez bloquer le trafic vers un ordinateur spécifique, il ne suffit pas de supprimer simplement les entrées d’adresse IP du nom de domaine complet du pool. Vous devez également supprimer l’entrée DNS de l’ordinateur.

Notez que pour le trafic de serveur à serveur, Skype Entreprise Server utilise l’équilibrage de charge prenant en charge la topologie. Les serveurs lisent la topologie publiée dans le magasin central de gestion pour obtenir les noms de domaine complets des serveurs dans la topologie et répartir automatiquement le trafic entre les serveurs. Pour empêcher un serveur de recevoir le trafic de serveur à serveur, vous devez supprimer le serveur de la topologie.