Détermination de la configuration requise pour DNS pour Lync Server 2013

  • Article

 

Rubrique Dernière modification : 2013-02-22

Utilisez le graphique de flux suivant pour déterminer les exigences du système de noms de domaine (DNS). Les modifications apportées aux mises à jour cumulatives pour Lync Server 2013 : février 2013 sont notées à l’endroit où elles s’appliquent.

Important

Microsoft Lync Server 2013 prend en charge l’utilisation de l’adressage IPv6. Pour utiliser des adresses IPv6, vous devez également prendre en charge le DNS IPv6 et configurer les enregistrements AAAA de l’hôte DNS (appelés « quad-A »). Dans les déploiements où IPv4 et IPv6 sont utilisés, il est préférable de configurer et de gérer les enregistrements A de l’hôte pour IPv4 et AAAA hôte pour IPv6. Même si votre déploiement est entièrement passé à IPv6, les enregistrements hôtes DNS IPv4 peuvent toujours être nécessaires lorsque des utilisateurs externes utilisent toujours IPv4.

Détermination du organigramme des exigences DNS

175782ac-363e-408a-912f-8991bf152970

Important

Par défaut, le nom d’ordinateur d’un ordinateur qui n’est pas joint à un domaine est un nom d’hôte, et non un nom de domaine complet (FQDN). Le générateur de topologie utilise des noms de domaine complets, et non des noms d’hôte. Vous devez donc configurer un suffixe DNS sur le nom de l’ordinateur qui sera déployé en tant que serveur de périphérie non lié à un domaine. Utilisez uniquement les caractères standard (tels que A–Z, a–z, 0–9, et les traits d’union) quand vous assignez les FQDN de vos serveurs Lync, serveurs de périphérie et pools. N’utilisez pas les caractères ou traits de soulignement Unicode. Souvent, les caractères non standard dans un FQDN ne sont pas pris en charge par le DNS externe et les autorités de certification publique (quand le FQDN doit être assigné au SN dans le certificat). Pour plus d’informations, consultez Configurer les enregistrements d’hôte DNS pour Lync Server 2013

Comment les clients Lync localisent les services

Microsoft Lync 2010, Lync 2013 et Lync Mobile sont similaires à la façon dont le client recherche et accède aux services dans Lync Server 2013. L’exception notable est l’application Lync du Windows Store qui utilise un autre processus d’emplacement de service. Cette section détaille deux scénarios de localisation des services par les clients, d’abord la méthode traditionnelle utilisant une série d’enregistrements hôtes SRV et A, d’autre part en utilisant uniquement les enregistrements du service de découverte automatique. Les mises à jour cumulatives des clients de bureau modifient le processus d’emplacement DNS à partir de Lync Server 2010 Pour tous les clients, le processus de requête DNS se poursuit jusqu’à ce qu’une requête réussie soit retournée, ou que la liste des enregistrements DNS possibles soit épuisée et que l’erreur finale soit retournée au client.

Pour tous les clients , à l’exception de l’application Lync du Windows Store lors de la recherche DNS, les enregistrements SRV sont interrogés et retournés au client dans l’ordre suivant :

  1. lyncdiscoverinternal.< enregistrement de domaine> A (hôte) pour le service de découverte automatique sur les services Web internes

  2. lyncdiscover.< enregistrement de domaine> A (hôte) pour le service de découverte automatique sur les services Web externes

  3. _sipinternaltls._tcp.< enregistrement SRV de domaine> (localisateur de service) pour les connexions TLS internes

  4. _sipinternal._tcp.< enregistrement SRV de domaine> (localisateur de service) pour les connexions TCP internes (effectuée uniquement si TCP est autorisé)

  5. _sip._tls.< enregistrement SRV de domaine> (localisateur de service) pour les connexions TLS externes

  6. sipinternal.< enregistrement de domaine> A (hôte) pour le pool frontal ou le directeur, pouvant être résolu uniquement sur le réseau interne

  7. Sip.< enregistrement de domaine> A (hôte) pour le pool frontal ou le directeur sur le réseau interne, ou le service Access Edge lorsque le client est externe

  8. sipexternal.< enregistrement de domaine> A (hôte) pour le service Access Edge lorsque le client est externe

L’application Lync du Windows Store modifie complètement le processus, car elle utilise deux enregistrements :

  1. lyncdiscoverinternal.< enregistrement de domaine> A (hôte) pour le service de découverte automatique sur les services Web internes

  2. lyncdiscover.< enregistrement de domaine> A (hôte) pour le service de découverte automatique sur les services Web externes

Il n’y a pas de secours pour les autres types d’enregistrements.

La différence entre les méthodes utilisées pour les clients plus récents par rapport aux clients plus anciens est que le service de découverte automatique devient la méthode préférée pour localiser tous les services.

Lorsqu’une connexion réussit, le service de découverte automatique retourne toutes les URL des services web pour le pool d’accueil de l’utilisateur, y compris le service Mobilité (appelé Mcx par le répertoire virtuel créé pour le service dans IIS), l’application web Microsoft Lync et les URL du planificateur web. Toutefois, l’URL interne du service Mobilité et l’URL du service mobilité externe sont associées au nom de domaine complet des services web externes. Par conséquent, qu’un appareil mobile soit interne ou externe au réseau, l’appareil se connecte toujours au service Mobilité en externe via le proxy inverse.

Si les mises à jour cumulatives pour Lync Server 2013 : février 2013 ont été installées, le service de découverte automatique retourne également des références à Internal/UCWA, External/UCWA et UCWA. Ces entrées font référence au composant web UCWA (Unified Communications Web API). Actuellement, seule l’entrée UCWA est utilisée et fournit une référence à une URL pour le composant web. UCWA est utilisé par les clients Lync 2013 Mobile au lieu du service Mobilité Mcx utilisé par les clients Lync 2010 Mobile.

Remarque

Lors de la création d’enregistrements SRV, il est important de se rappeler qu’ils doivent pointer vers un enregistrement DNS A et AAAA (si vous utilisez l’adressage IPv6) dans le même domaine dans lequel l’enregistrement SRV DNS est créé. Par exemple, si l’enregistrement SRV est dans contoso.com, l’enregistrement A et AAAA (si vous utilisez l’adressage IPv6) qu’il pointe ne peut pas se trouver dans fabrikam.com.

Pointe

La configuration par défaut consiste à diriger tout le trafic client mobile via le site externe. Vous pouvez modifier les paramètres pour renvoyer uniquement l’URL interne, si cela est préférable à vos besoins. Avec cette configuration, les utilisateurs peuvent utiliser des applications mobiles Lync sur leurs appareils mobiles uniquement lorsqu’ils se trouvent à l’intérieur du réseau d’entreprise. Pour définir cette configuration, vous utilisez l’applet de commande Set-CsMcxConfiguration .

Remarque

Bien que les applications mobiles puissent également se connecter à d’autres services Lync Server 2013, tels que le service carnet d’adresses, les demandes web d’application mobile internes sont envoyées au nom de domaine complet web externe uniquement pour le service Mobilité. D’autres demandes de service, telles que les demandes de carnet d’adresses, ne nécessitent pas cette configuration.

Les appareils mobiles prennent en charge la découverte manuelle des services. Dans ce cas, chaque utilisateur doit configurer les paramètres de l’appareil mobile avec l’intégralité des URI internes et externes du service de découverte automatique, y compris le protocole et le chemin d’accès, comme suit :

  • <https:// ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root pour l’accès externe

  • <https:// IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root pour l’accès interne

Nous vous recommandons d’utiliser la détection automatique, plutôt que la découverte manuelle. Toutefois, les paramètres manuels peuvent être utiles pour résoudre les problèmes de connectivité des appareils mobiles.

Configuration Split-Brain DNS avec Lync Server

Le DNS split-brain est connu par un certain nombre de noms, par exemple, DNS fractionné ou DNS à horizon fractionné. Il décrit simplement une configuration DNS où il existe deux zones DNS avec le même espace de noms , mais une zone DNS services des demandes internes uniquement, et l’autre zone DNS services des requêtes externes uniquement. Toutefois, la plupart des enregistrements DNS SRV et A contenus dans le DNS interne ne seront pas contenus dans le DNS externe, et l’inverse est également vrai. Dans les cas où le même enregistrement DNS existe dans le DNS interne et externe (par exemple, www.contoso.com), l’adresse IP retournée est différente en fonction de l’endroit (interne ou externe) où la requête a été lancée.

Important

Actuellement, Split-Brain DNS n’est pas pris en charge pour la mobilité, ni plus précisément pour les enregistrements DNS LyncDiscover et LyncDiscoverInternal. LyncDiscover doit être défini sur un serveur DNS externe et LyncDiscoverInternal doit être défini sur un serveur DNS interne.

Pour les besoins de ces rubriques, le terme DNS split-brain sera utilisé.

Si vous configurez le DNS split-brain, la zone interne et externe suivante contient un récapitulatif des types d’enregistrements DNS requis dans chaque zone. Pour plus d’informations, consultez Scénarios d’accès des utilisateurs externes dans Lync Server 2013.

DNS interne :

  • Contient une zone DNS appelée contoso.com pour laquelle elle fait autorité

  • La zone de contoso.com interne contient :

    • DNS A et AAAA (si vous utilisez l’adressage IPv6) et les enregistrements SRV pour la configuration automatique du client Lync Server 2013 interne (facultatif)

    • Enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) ou CNAME pour la découverte automatique des services web Lync Server 2013 (facultatif)

    • Enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) pour le nom du pool frontal, le nom du pool d’administrateurs ou de directeurs, et tous les serveurs internes exécutant Lync Server 2013 dans le réseau d’entreprise

    • Enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) pour l’interface interne Edge de chaque serveur Lync Server 2013, serveur Edge dans le réseau de périmètre

    • Enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) pour l’interface interne de chaque serveur proxy inverse dans le réseau de périmètre (facultatif pour la gestion du proxy inverse)

    • Toutes les interfaces edge internes du serveur Edge Lync Server 2013 dans le réseau de périmètre utilisent la zone DNS interne pour résoudre les requêtes contoso.com

    • Tous les serveurs exécutant Lync Server 2013 et les clients exécutant Lync 2013 dans le réseau d’entreprise pointent vers les serveurs DNS internes pour résoudre les requêtes à contoso.com, ou l’utilisation du fichier HOSTS sur chaque serveur Edge et répertorient les enregistrements A et AAAA (si vous utilisez l’adressage IPv6) pour le serveur de tronçon suivant, en particulier l’adresse IP virtuelle du directeur ou du directeur, Adresse IP virtuelle du pool frontal ou serveur Standard Edition

DNS externe :

  • Contient une zone DNS appelée contoso.com pour laquelle elle fait autorité

  • La zone de contoso.com externe contient :

    • DNS A et AAAA (si vous utilisez l’adressage IPv6) et les enregistrements SRV pour la configuration automatique du client Lync Server 2013 (facultatif)

    • Enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) ou CNAME pour la découverte automatique des services web Lync Server 2013 à utiliser avec mobilité

    • Enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) et SRV pour l’interface externe Edge de chaque adresse IP virtuelle (VIP) Lync Server 2013, Serveur Edge ou équilibreur de charge matériel dans le réseau de périmètre

    • Enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) pour l’interface externe du serveur proxy inverse ou vip pour un pool de serveurs proxy inverses dans le réseau de périmètre

Configuration automatique sans DNS Split-Brain

À l’aide du DNS split-brain, un utilisateur Lync Server 2013 qui se connecte en interne peut tirer parti de la configuration automatique si la zone DNS interne contient un enregistrement SRV _sipinternaltls._tcp pour chaque domaine SIP utilisé. Toutefois, si vous n’utilisez pas le DNS split-brain, la configuration automatique interne des clients exécutant Lync ne fonctionnera pas, sauf si l’une des solutions de contournement décrites plus loin dans cette section est implémentée. En effet, Lync Server 2013 nécessite que l’URI SIP de l’utilisateur corresponde au domaine du pool frontal désigné pour la configuration automatique. C’était également le cas avec les versions antérieures de Communicator.

Par exemple, si vous avez deux domaines SIP en service, les enregistrements de service DNS (SRV) suivants sont requis :

  • Si un utilisateur se connecte en tant qu’enregistrement bob@contoso.com SRV suivant fonctionne pour la configuration automatique, car le domaine SIP (contoso.com) de l’utilisateur correspond au domaine du pool frontal de configuration automatique) :

     _sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com

  • Si un utilisateur se connecte en tant qu’enregistrement alice@fabrikam.com SRV DNS suivant, cela fonctionne pour la configuration automatique du deuxième domaine SIP.

     _sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Pour comparaison, si un utilisateur se connecte en tant qu’enregistrement tim@litwareinc.com SRV DNS suivant ne fonctionne pas pour la configuration automatique, car le domaine SIP du client (litwareinc.com) ne correspond pas au domaine dans lequel se trouve le pool (fabrikam.com) :

 _sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

Si la configuration automatique est requise pour les clients exécutant Lync, sélectionnez l’une des options suivantes :

  • stratégie de groupe Les objets utilisent des objets stratégie de groupe (GPO) pour remplir les valeurs de serveur correctes.

    Remarque

    Cette option n’active pas la configuration automatique, mais elle automatise le processus de configuration manuelle. Par conséquent, si cette approche est utilisée, les enregistrements SRV associés à la configuration automatique ne sont pas nécessaires.

  • Correspondance d’une zone interne Créez une zone dans le DNS interne qui correspond à la zone DNS externe (par exemple, contoso.com) et créez des enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) correspondant au pool Lync Server 2013 utilisé pour la configuration automatique. Par exemple, si un utilisateur est hébergé sur pool01.contoso.net mais se connecte à Lync en tant que bob@contoso.com, créez une zone DNS interne appelée contoso.com et à l’intérieur, créez un enregistrement DNS A et AAAA (si l’adressage IPv6 est utilisé) pour pool01.contoso.com.

  • Zone interne de point d’épingle Si vous créez une zone entière dans le DNS interne n’est pas une option, vous pouvez créer des zones de point d’épingle (c’est-à-dire dédiées) qui correspondent aux enregistrements SRV requis pour la configuration automatique et remplir ces zones à l’aide de dnscmd.exe. Dnscmd.exe est nécessaire, car l’interface utilisateur DNS ne prend pas en charge la création de zones de point d’épingle. Par exemple, si le domaine SIP est contoso.com et que vous disposez d’un pool frontal appelé pool01 qui contient deux serveurs frontaux, vous avez besoin des zones de point d’épingle suivantes et des enregistrements A dans votre DNS interne :

    dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com.
dnscmd . /zoneadd pool01.contoso.com. /dsprimary
dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90
dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91 
dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>

    Si votre environnement contient un deuxième domaine SIP (par exemple, fabrikam.com), vous avez besoin des zones de point d’épingle et des enregistrements A suivants dans votre DNS interne :

    dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary
dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com.
dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary
dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90
dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91
dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>

Remarque

Le nom de domaine complet du pool frontal s’affiche deux fois, mais avec deux adresses IP différentes. Cela est dû au fait que l’équilibrage de charge DNS est utilisé, mais si l’équilibrage de charge matérielle est utilisé, il n’y aurait qu’une seule entrée de pool frontal. En outre, les valeurs de nom de domaine complet du pool frontal changent entre l’exemple contoso.com et l’exemple fabrikam.com, mais les adresses IP restent les mêmes. Cela est dû au fait que les utilisateurs qui se connectent à partir d’un domaine SIP utilisent le même pool frontal pour la configuration automatique.

Pour plus d’informations, consultez l’article de blog DMTF« Communicator Automatic Configuration and Split-Brain DNS », à l’adresse https://go.microsoft.com/fwlink/p/?linkId=200707.

Remarque

Le contenu des blogs et leurs URL peuvent être modifiés sans préavis.

Configuration du système de noms de domaine (DNS) pour la récupération d’urgence

Pour configurer DNS afin de rediriger le trafic web Lync Server 2013 vers vos sites de récupération d’urgence et de basculement, vous devez utiliser un fournisseur DNS qui prend en charge GeoDNS. Vous pouvez configurer vos enregistrements DNS pour le web afin de prendre en charge la récupération d’urgence, afin que les fonctionnalités qui utilisent les services Web continuent même si un pool frontal entier tombe en panne. Cette fonctionnalité de récupération d’urgence prend en charge les URL simples de découverte automatique (URL de découverte de Lync), de réunion et de connexion.

Vous définissez et configurez des enregistrements hôtes DNS supplémentaires (A et AAAA si vous utilisez IPv6) pour la résolution interne et externe des services Web auprès de votre fournisseur GeoDNS. Les détails suivants supposent que les pools appairés, géographiquement dispersés et GeoDNS pris en charge par votre fournisseur avec un DNS par tourniquet (round robin), ou configurés pour utiliser Pool1 comme principal, et basculent vers Pool2 en cas de perte de communication ou de défaillance matérielle.

Enregistrement GeoDNS (exemple) Enregistrements de pool (exemple) Enregistrements CNAME (exemple) Paramètres DNS (sélectionnez une option)

Meet-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Meet.contoso.com alias de Pool1InternalWebFQDN.contoso.com

Meet.contoso.com alias de Pool2InternalWebFQDN.contoso.com

Round Robin entre pools

Utiliser le serveur principal, se connecter à une base de données secondaire en cas d’échec

Meet-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Meet.contoso.com alias de Pool1ExternalWebFQDN.contoso.com

Meet.contoso.com alias de Pool2ExternalWebFQDN.contoso.com

Round Robin entre pools

Utiliser le serveur principal, se connecter à une base de données secondaire en cas d’échec

Dialin-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Dialin.contoso.com alias de Pool1InternalWebFQDN.contoso.com

Dialin.contoso.com alias de Pool2InternalWebFQDN.contoso.com

Round Robin entre pools

Utiliser le serveur principal, se connecter à une base de données secondaire en cas d’échec

Dialin-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Dialin.contoso.com alias de Pool1ExternalWebFQDN.contoso.com

Dialin.contoso.com alias de Pool2ExternalWebFQDN.contoso.com

Round Robin entre pools

Utiliser le serveur principal, se connecter à une base de données secondaire en cas d’échec

Lyncdiscoverint-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Lyncdiscoverinternal.contoso.com alias de Pool1InternalWebFQDN.contoso.com

Lyncdiscoverinternal.contoso.com alias de Pool2InternalWebFQDN.contoso.com

Round Robin entre pools

Utiliser le serveur principal, se connecter à une base de données secondaire en cas d’échec

Lyncdiscover-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Lyncdiscover.contoso.com alias de Pool1ExternalWebFQDN.contoso.com

Lyncdiscover.contoso.com alias de Pool2ExternalWebFQDN.contoso.com

Round Robin entre pools

Utiliser le serveur principal, se connecter à une base de données secondaire en cas d’échec

Scheduler-int.geolb.contoso.com

Pool1InternalWebFQDN.contoso.com

Pool2InternalWebFQDN.contoso.com

Scheduler.contoso.com alias de Pool1InternalWebFQDN.contoso.com

Scheduler.contoso.com alias de Pool2InternalWebFQDN.contoso.com

Round Robin entre pools

Utiliser le serveur principal, se connecter à une base de données secondaire en cas d’échec

Scheduler-ext.geolb.contoso.com

Pool1ExternalWebFQDN.contoso.com

Pool2ExternalWebFQDN.contoso.com

Scheduler.contoso.com alias de Pool1ExternalWebFQDN.contoso.com

Scheduler.contoso.com alias de Pool2ExternalWebFQDN.contoso.com

Round Robin entre pools

Utiliser le serveur principal, se connecter à une base de données secondaire en cas d’échec

DNS Load Balancing

L’équilibrage de charge DNS est généralement implémenté au niveau de l’application. L’application (par exemple, un client exécutant Lync) tente de se connecter à un serveur dans un pool en se connectant à l’une des adresses IP retournées par le 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 événements suivants se produisent :

  • Les clients exécutant le DNS de requête Lync 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 informé qu’aucun serveur exécutant Lync Server 2013 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 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 (round robin) DNS est en soi moins fiable que l’équilibrage de charge DNS. Vous pouvez utiliser le tourniquet (round robin) 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 vers les serveurs Edge

  • Équilibrage de charge des applications UCAS (Unified Communications Application Services), telles que le standard automatique de conférence, le groupe de réponses et le parc d’appels

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

  • É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 des serveurs d’annuaire 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 Access Edge 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 « A DNS RR for specifying the location of services (DNS SRV) » http://www.ietf.org/rfc/rfc2782.txt du groupe de travail d’ingénierie Internet spécifie que, s’il existe plusieurs enregistrements SRV DNS définis, la priorité est d’abord utilisée, puis le poids. Par exemple, l’enregistrement SRV DNS 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 SRV DNS A avec la priorité 40 est sélectionné. Les règles suivantes s’appliquent à la sélection d’enregistrements SRV DNS :

  • 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 de pondération spécifie un poids relatif pour les entrées ayant la même priorité. Les poids plus grands DOIVENT avoir une probabilité proportionnellement plus élevée d’être sélectionnés. Les administrateurs DNS DOIVENT utiliser Weight 0 lorsqu’il n’y a aucune 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 Access Edge sélectionne l’enregistrement SRV qui a été reçu en premier à partir du serveur DNS.