Option de configuration DNS pour les serveurs Adobe Connect Edge

Rechercher

Dernière mise à jour le 18 janv. 2022 | S’applique également à Adobe Connect 9

Problème

Cette note technique est destinée à être utilisée en complément du Guide d’installation et de configuration d’Adobe Connect Enterprise Server 6.

Les serveurs Edge consolident les données à un emplacement distant, ils regroupent celles qu’ils ne peuvent pas gérer eux-mêmes et les transmettent à un serveur d’origine. Pour qu’un serveur Edge puisse effectuer sa tâche, le serveur DNS dans l’emplacement ou les emplacements distants doit être configuré correctement.

Observez la mise en œuvre du serveur Edge ci-dessus chez Example Co. Le serveur d’origine à Chicago est installé depuis un certain temps. Les utilisateurs à Tokyo et à Paris, ainsi qu’à d’autres endroits du monde, l’utilisent en production. De nombreux utilisateurs Connect se trouvent à Tokyo et à Paris. C’est pourquoi il a été décidé d’y installer un serveur Edge.

Nom de domaine pleinement qualifié (FQDN)	Type	Adresse IP
connect.example.com	Origine	10.7.215.10
edge.tokyo.example.com	Edge	10.7.145.11
edge.paris.example.com	Edge	10.7.95.12

Remarque : Les noms de domaine et les adresses IP indiqués ci-dessus sont uniquement des exemples.

Avant la mise en œuvre du serveur Edge, un utilisateur à Tokyo, Paris, Chicago ou n’importe où chez Example Co. ouvrait un navigateur et entrait l’URL http://connect.example.com pour démarrer une session Connect. Il existait (et il existe toujours) un serveur DNS à Chicago, Paris et Tokyo, ainsi qu’à d’autres endroits, qui partagent tous les mêmes mappages DNS. Une structure DNS comme celle-ci est appelée « Système DNS centralisé ». Comme le système DNS est « centralisé », tous partagent la même table de mappage. Ainsi, quel que soit l’emplacement d’un utilisateur, connect.example.com résout 10.7.215.10. Malheureusement, cela pose un problème une fois les serveurs Edge installés.

Une fois les serveurs Edge installés, un utilisateur à Tokyo doit être mappé sur 10.7.145.11 (edge.tokyo.example.com) lorsqu’il entre http://connect.example.com, et non sur 10.7.215.10 (connect.example.com). Un utilisateur à Paris doit accéder à 10.7.95.12. Comment configurer cela si un système DNS centralisé partage la même table de mappage (connect.example.com est toujours mappé sur 10.7.215.10 où que vous vous trouviez) ? La réponse consiste à utiliser la « Hiérarchisation des sous-réseaux ».

Solution

Une fois la « Hiérarchisation des sous-réseaux » configurée, le système DNS centralisé renvoie une liste d’adresses IP dont l’ordre est basé sur l’emplacement du client (utilisateur). Ainsi, dans notre exemple, un utilisateur à Paris qui entre http://connect.example.com obtient une liste telle que 10.7.95.12, 10.7.145.11, 10.7.215.10 (Paris, Tokyo, Chicago), un utilisateur à Tokyo obtient une liste telle que 10.7.145.11, 10.7.95.12, 10.7.215.10 (Tokyo, Paris, Chicago), et tout autre utilisateur obtient 10.7.215. 10, 10.7.145.11, 10.7.95.12, (Chicago, Tokyo, Paris). Cette solution résout le problème pour Connect. Désormais, les utilisateurs de Paris et de Tokyo sont redirigés vers leurs serveurs Edge locaux lorsqu’ils accèdent à Connect. Tous les autres utilisateurs accèdent directement au serveur d’origine.

Si le système DNS n’est pas « Centralisé », c’est-à-dire que les serveurs DNS ne partagent pas la table de mappage, la « Hiérarchisation des sous-réseaux » n’est pas nécessaire : chaque serveur DNS peut être configuré individuellement.

Vous trouverez des informations sur la configuration de la « Hiérarchisation des sous-réseaux » sur le site Web Microsoft.

Deux points doivent être pris en compte :

Si le client tente de résoudre connect.example.com et qu’il n’y a pas d’entrée DNS pour ce sous-réseau de clients, lorsqu’il renvoie les adresses IP au client, il place la dernière entrée DNS entrée dans la base de données/table DNS en tant que première ligne sur le cache DNS du client. Ainsi, si un serveur Edge est ajouté après que le système DNS a été configuré pour une implémentation avec le serveur d’origine uniquement (comme dans cet exemple), l’entrée DNS pour le serveur d’origine doit être supprimée, puis rajoutée afin d’apparaître comme dernière entrée.
Il existe un petit problème au sujet de la façon dont « Hiérarchisation des sous-réseaux » gère le masque de sous-réseau et la classe de réseau. Les serveurs DNS doivent être des serveurs Windows 2003 et la fonction de tourniquet (round robin) doit être désactivée. Consultez l’article de support Microsoft http://support.microsoft.com/kb/842197.