Partager via

Planifier le déploiement du serveur Edge avancé pour Skype Entreprise Server

  • Article

Résumé: Passez en revue les scénarios pour Skype Entreprise Server options de déploiement. Que vous souhaitiez un serveur unique ou préférez un pool de serveurs avec DNS ou HLB, cette rubrique devrait vous aider.

Quand il s’agit de la planification dns (Domain Name System) pour Skype Entreprise Server, de nombreux facteurs peuvent jouer dans votre décision. Si la structure de domaines de votre organisation est déjà en place, la question est peut-être de réviser la façon dont vous allez procéder. Commençons par les rubriques situées ci-dessous :

Walkthrough of Skype for Business clients locating services

Skype Entreprise clients sont similaires aux versions précédentes des clients Lync dans la façon dont ils recherchent et accèdent aux services dans Skype Entreprise Server. Cette section aborde en détail le processus d’emplacement du serveur.

  1. lyncdiscoverinternal.<Domaine>

    Il s’agit d’un enregistrement d’hôte A pour le service de découverte automatique sur les services web internes.

  2. lyncdiscover.<Domaine>

    Il s’agit d’un enregistrement d’hôte A pour le service de découverte automatique sur les services web internes.

  3. _sipinternaltls._tcp.<Domaine>

    Il s’agit d’un enregistrement SRV pour les connexions TLS internes.

  4. _sip._tls.<Domaine>

    Il s’agit d’un enregistrement SRV pour les connexions TLS externes.

  5. sipinternal.<Domaine>

    Il s’agit d’un enregistrement d’hôte A pour le pool frontal ou le directeur, pouvant être résolu uniquement sur le réseau interne.

  6. Sip.<Domaine>

    Il s’agit d’un enregistrement d’hôte A pour le pool frontal ou le directeur, pouvant être résolu uniquement sur le réseau interne.

  7. sipexternal.<Domaine>

    Il s’agit d’un enregistrement hôte A pour le service Access Edge, lorsque le client est externe.

Le service de découverte automatique est toujours privilégié, car il s’agit de la méthode préférée pour l’emplacement du service, et les autres sont des méthodes de secours.

Remarque

Lorsque vous créez des enregistrements SRV, il est important de ne pas oublier qu’ils doivent pointer vers un DNS A (et AAAA si vous utilisez l’adressage IPv6) dans le même domaine que celui sur lequel l’enregistrement DNS SRV est créé. Par exemple, si l’enregistrement SRV se trouve dans contoso.com, l’enregistrement A (et AAAA) vers lequel il pointe ne peut pas se trouver dans fabrikam.com.

Si vous avez vraiment envie d’y parvenir, vous pouvez configurer votre appareil mobile à la découverte manuelle des services. Si c’est ce que vous cherchez à faire, chaque utilisateur doit configurer ses paramètres de l’appareil mobile avec les URI complètes interne et externe du service de découverte automatique, dont le protocole et le chemin d’accès, comme suit :

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

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

Nous vous recommandons l’utilisation de la découverte automatique par opposition à la découverte manuelle. Mais si vous faites de la résolution de problèmes ou des tests, les paramètres manuels peuvent être très utiles.

DNS split-brain

Il s’agit d’une configuration DNS où vous avez deux zones DNS avec le même espace de noms. La première zone DNS traite les demandes internes, tandis que la deuxième zone DNS traite les requêtes.

Pourquoi une société fait-elle ceci ? Peut-être à cause d’une obligation d’utiliser le même espace de noms en interne et en externe, mais, bien sûr, vous aboutissez ainsi à de nombreux enregistrements DNS SRV et A qui sont uniques pour une zone ou une autre et, là où il y a duplication, les adresses IP associées à ces enregistrements sont uniques.

Cela présente certains défis. Le plus important est que le DNS split-brain n’est pas pris en charge pour Mobility. Ceci est dû aux enregistrements DNS LyncDiscover et LyncDiscoverInternal (LyncDiscover doit être défini sur votre serveur DNS externe, tandis que LyncDiscoverInternal doit être défini sur votre serveur DNS interne).

Nous allons répertorier ici les enregistrements DNS pour les zones internes et externes, mais vous trouverez des exemples détaillés dans la section Exigences environnementales du serveur Edge.

DNS interne

  • Contient une zone DNS appelée (par exemple) contoso.com, pour laquelle il fait autorité.

  • Ce contoso.com interne contient :

    • Enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) pour votre pool frontal, pool de directeurs ou nom du pool de directeurs, et tous les serveurs internes exécutant Skype Entreprise Server dans le réseau de votre organization.

    • Enregistrements DNS A et AAAA (si vous utilisez l’adressage IPv6) pour votre interface interne Edge pour chaque serveur Skype Entreprise Server Edge dans votre 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 votre réseau de périmètre (ce qui est facultatif pour la gestion d’un proxy inverse).

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

    • DNS A et AAAA (si vous utilisez l’adressage IPv6) ou des enregistrements CNAME pour la détection automatique des services web Skype Entreprise Server (ce qui est facultatif).

  • Toutes vos interfaces edge internes Skype Entreprise Server dans votre réseau de périmètre utilisent cette zone DNS interne pour résoudre les requêtes contoso.com.

  • Tous les serveurs exécutant Skype Entreprise Server et les clients exécutant Skype Entreprise Server dans le réseau d’entreprise pointent vers des serveurs DNS internes pour résoudre les requêtes vers contoso.com, ou ils utilisent le fichier hôte 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 pour l’adresse IP virtuelle du pool directeur ou directeur, Adresse IP virtuelle du pool frontal ou serveur Standard Edition).

DNS externe

  • Contient une zone DNS appelée (par exemple) contoso.com, pour laquelle il fait autorité.

  • Ce contoso.com externe contient :

    • DNS A et AAAA (si vous utilisez l’adressage IPv6) ou des enregistrements CNAME pour la détection automatique des services web Skype Entreprise Server. Ils s’utilisent avec la mobilité.

    • DNS A et AAAA (si vous utilisez l’adressage IPv6) et les enregistrements SRV pour l’interface externe Edge de Skype Entreprise Server chaque serveur Edge ou adresse IP virtuelle à charge équilibrée (HLB) du réseau de périmètre.

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

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

Configuration automatique sans DNS Split-Brain

Si vous n’utilisez pas le DNS à cerveau partagé, la configuration automatique interne des clients exécutant Skype Entreprise ne fonctionnera pas, sauf si vous utilisez l’une des solutions de contournement que nous avons ici. Pourquoi ? Étant donné que Skype Entreprise Server nécessite que l’URI SIP de l’utilisateur corresponde au domaine du pool frontal désigné pour la configuration automatique. Cela n’a pas changé par rapports aux versions antérieures de Lync Server.

Par conséquent, si vous avez deux domaines SIP (Session Initiation Protocol) utilisés, vous avez besoin de ces enregistrements SRV DNS :

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

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

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

    Si un utilisateur se connecte en tant que alice@fabrikam.com, cet enregistrement fonctionne pour la configuration automatique du deuxième domaine, là encore, car le domaine SIP correspond au pool frontal pour ce domaine.

Pour développer l’exemple, cela ne fonctionne pas :

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

    Un utilisateur qui se connecte en tant que tim@litwareinc.com ne fonctionne pas pour la configuration automatique, car son domaine SIP (litwareinc.com) ne correspond pas au domaine du pool (fabrikam.com).

Maintenant que nous savons tout cela, si vous avez besoin d’une exigence automatique pour vos clients Skype Entreprise sans DNS split-brain, vous avez les options suivantes :

  • Objets de stratégie de groupe

    Vous pouvez utiliser des objets de stratégie de groupe (GPO) pour remplir le serveur avec les valeurs correctes.

    Remarque

    Cette option ne permet pas d’autoriser la configuration automatique, mais elle automatise la configuration manuelle. Si cette approche est utilisée, les enregistrements SRV associés à la configuration automatique ne sont pas obligatoires.

  • Zone interne correspondante

    Vous devez créer une zone dans votre DNS interne qui correspond à votre zone DNS externe (par exemple, contoso.com), puis créer des enregistrements DNS A (et AAAA si vous utilisez l’adressage IPv6) qui correspondent au pool Skype Entreprise Server utilisé pour la configuration automatique.

    Par exemple, si vous avez un utilisateur hébergé sur pool01.contoso.net, mais qu’il se connecte à Skype Entreprise en tant que bob@contoso.com, créez une zone DNS interne appelée contoso.com et à l’intérieur de celle-ci, vous devez créer un enregistrement DNS A (et AAAA si l’adressage IPv6 est utilisé) pour pool01.contoso.com.

  • Repérage de la zone interne

    Si la création d’une zone complète dans votre DNS interne n’est pas envisageable pour vous, vous pouvez créer des zones repère (dédiées) qui correspondent aux enregistrements SRV requis pour la configuration automatique, et renseigner ces zones à l’aide de dnscmd.exe. Dnscmd.exe est obligatoire car l’interface utilisateur DNS ne prendra pas en charge la création de zones repère.

    Par exemple, si votre domaine SIP est contoso.com et que vous disposez d’un pool frontal appelé pool01 qui contient deux serveurs frontaux, vous aurez besoin des zones de point d’épingle et des enregistrements A suivants 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>

    Vous avez peut-être un second domaine SIP (Session Initiation Protocol) dans votre environnement. Dans ce cas, vous avez besoin des zones repère 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. C’est parce que l’équilibrage de charge DNS est utilisé. Si HLB est utilisé, il n’y a qu’une seule entrée de pool frontal.

Remarque

En outre, les valeurs de nom de domaine complet du pool frontal changent entre les exemples contoso.com et fabrikam.com, mais les adresses IP restent les mêmes. En effet, les utilisateurs qui se connectent à partir d’un domaine SIP utilisent le même pool frontal pour la configuration automatique.

DNS disaster recovery

Pour configurer dns afin de rediriger Skype Entreprise Server trafic web 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 prendre en charge la récupération d’urgence, afin que les fonctionnalités qui utilisent des services web continuent même si un pool frontal complet tombe en panne. Cette fonctionnalité DR prend en charge les URL simples de découverte automatique, de réunion et de rendez-vous.

Vous définissez et configurez des enregistrements d’hôte DNS A (AAAA en cas d’utilisation d’IPv6) supplémentaires pour la résolution interne et externe des services web au niveau de votre fournisseur GeoDNS. Les détails suivants supposent que les pools appairés, dispersés géographiquement, et que le GeoDNS pris en charge par votre fournisseur dispose d’un DNS tourniquet ou est configuré pour utiliser Pool1 comme principal et bascule vers Pool2 en cas de perte de communication ou de panne de courant.

Tous les enregistrements DNS dans ce tableau sont des exemples.

Enregistrement GeoDNS Enregistrements de pool Enregistrements CNAME Paramètres DNS (sélectionnez une option)
Meet-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com à Meet-int.geolb.contoso.com

 Round Robin entre pools
SOIT
Utilisation du principal, connexion au secondaire en cas de défaillance
Meet-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com à Meet-ext.geolb.contoso.com

 Round Robin entre pools
SOIT
Utilisation du principal, connexion au secondaire en cas de défaillance
Dialin-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com à Meet-int.geolb.contoso.com

 Round Robin entre pools
SOIT
Utilisation du principal, connexion au secondaire en cas de défaillance
Dialin-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com à Meet-ext.geolb.contoso.com

 Round Robin entre pools
SOIT
Utilisation du principal, connexion au secondaire en cas de défaillance
Lyncdiscoverint-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com à Meet-int.geolb.contoso.com

 Round Robin entre pools
SOIT
Utilisation du principal, connexion au secondaire en cas de défaillance
Lyncdiscover-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com à Meet-ext.geolb.contoso.com

 Round Robin entre pools
SOIT
Utilisation du principal, connexion au secondaire en cas de défaillance
Scheduler-int.geolb.contoso.com
 Pool1InternalWebFQDN.contoso.com
Pool2InternalWebFQDN.contoso.com
 Meet.contoso.com à Meet-int.geolb.contoso.com

 Round Robin entre pools
SOIT
Utilisation du principal, connexion au secondaire en cas de défaillance
Scheduler-ext.geolb.contoso.com
 Pool1ExternalWebFQDN.contoso.com
Pool2ExternalWebFQDN.contoso.com
 Meet.contoso.com à Meet-ext.geolb.contoso.com

 Round Robin entre pools
SOIT
Utilisation du principal, connexion au secondaire en cas de défaillance

Équilibrage de charge DNS

L’équilibrage de charge DNS est généralement mis en œuvre 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 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 renvoie trois adresses IP et les met dans le 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 essaie d’établir une connexion TCP à l’une des adresses IP. En cas d’échec, il essaiera l’adresse IP suivante qu’elle sera mise en cache à partir de cette liste.

  • 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 reçoit une notification indiquant 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 (round robin) DNS (DNS RR), qui fait généralement référence à l’équilibrage de charge en s’appuyant sur DNS pour donner un ordre d’adresses IP différent pour les serveurs dans votre pool. En règle générale, DNS RR active la distribution de la charge, mais il ne vous permettra pas d’activer le basculement. Par exemple, si la connexion à l’adresse IP renvoyée par votre requête DNS (ou AAAA dans un scénario IPv6) échoue, cette connexion échouera. Cela rend DNS RR moins fiable que l’équilibrage de charge DNS. Vous pouvez toujours utiliser DNS RR conjointement avec l’équilibrage de charge DNS si vous avez besoin de procéder ainsi.

Vous utilisez l’équilibrage de charge DNS pour :

  • Équilibrez la charge sip de serveur à serveur sur les serveurs Edge.

  • équilibrer la charge des applications des services d’applications de communications unifiées (UCAS) telles que le Standard automatique de conférence, Response Group et le parcage d’appel ;

  • empêcher les nouvelles connexions aux applications UCAS (également appelé « drainage ») ;

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

Vous ne pouvez pas utiliser l’équilibrage de charge DNS pour :

  • Trafic web client à serveur vers vos serveurs frontaux ou un directeur.

Pour approfondir la façon dont un enregistrement SRV DNS est sélectionné lorsque plusieurs enregistrements DNS sont retournés par une requête, le service Access Edge sélectionne toujours l’enregistrement avec la priorité numérique la plus basse et, si un équilibreur de liaison est nécessaire, la pondération numérique la plus élevée. Cela est conforme à la documentation du Groupe de travail d’ingénierie Internet.

Ainsi, par exemple, si votre premier enregistrement DNS SRV a un poids de 20 et une priorité de 40, et votre deuxième enregistrement SRV DNS a une valeur de 10 et une priorité de 50, le premier enregistrement va être choisi car il a la priorité basse de 40. La priorité vient toujours d’abord, et c’est l’hôte qu’un client va cibler le premier. Que se passe-t-il s’il existe deux cibles ayant la même priorité ?

Dans ce cas, le poids vient en considération. Les poids les plus élevés doivent recevoir une forte probabilité d’être sélectionnés dans ces conditions. Les administrateurs DNS doivent utiliser un poids égal à 0 quand 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 ont une faible chance d’apporter sélectionné.

Alors, que se passe-t-il si plusieurs SRV DNS de même priorité et de même poids s’enregistrent comme renvoyés ? Dans ce cas, le service Edge d’accès choisit d’abord l’enregistrement SRV obtenu à partir du serveur DNS.