Volledig gekwalificeerde domeinnaam (FQDN)
DNS-configuratieoptie voor Adobe Connect Edge-servers
Probleem
Deze TechNote is bedoeld om als supplement bij de Handleiding voor installatie en configuratie van Adobe Connect Enterprise Server 6 te gebruiken.
Edge-servers verzamelen gegevens op een externe locatie, verpakken de gegevens die ze niet zelf kunnen verwerken en geven die door naar een Origin-server. De DNS-server op de externe locaties moeten goed geconfigureerd zijn, zodat een Edge-server zijn taak kan uitvoeren.
Zie de bovenstaande Edge-serverimplementatie bij Voorbeeld Co. De Origin-server in Chicago is enige tijd geleden geïnstalleerd en gebruikers in Tokio en Parijs, maar ook op andere locaties wereldwijd, gebruiken deze in productie. Er is een behoorlijk aantal Connect-gebruikers in Tokio en Parijs en daarom is besloten om een Edge-server op deze locaties te installeren.
|
Type |
IP-adres |
connect.example.com |
Origin |
10.7.215.10 |
edge.tokyo.example.com |
Edge |
10.7.145.11 |
edge.paris.example.com |
Edge |
10.7.95.12 |
Opmerking: De hierboven vermelde domeinnamen en IP-adressen zijn slechts voorbeelden.
Voorafgaand aan de implementatie van de Edge-server zou een gebruiker in Tokio, Parijs, Chicago of waar dan ook bij Voorbeeld Co. een browser openen en de URL http://connect.example.com intypen om een Connect-sessie te starten. Er was (en is nog steeds) een DNS-server in Chicago, Parijs en Tokio en op andere locaties die allemaal dezelfde DNS-toewijzingen delen. Een dergelijke DNS-structuur wordt een 'gecentraliseerd DNS-systeem' genoemd. Doordat het DNS-systeem 'gecentraliseerd' is, delen ze allemaal dezelfde toewijzingstabel; het maakt dus niet uit waar een gebruiker zich bevindt, connect.example.com wordt omgezet naar 10.7.215.10. Dit levert helaas een probleem op zodra de Edge-servers zijn geïnstalleerd.
Nadat de Edge-servers zijn geïnstalleerd, moet een gebruiker in Tokio bij het invoeren van http://connect.example.com worden verwezen naar 10.7.145.11 (edge.tokyo.example.com) en niet naar 10.7.215.10 (connect.example.com). Een gebruiker in Parijs moet naar 10.7.95.12 gaan. Hoe kan dit worden geconfigureerd als een gecentraliseerd DNS-systeem dezelfde toewijzingstabel deelt (connect.example.com verwijst altijd naar 10.7.215.10 ongeacht waar u zich bevindt)? Dit kan worden opgelost door 'prioriteitstelling voor subnetten' te gebruiken.
Oplossing
Als 'prioriteitstelling voor subnetten' is geconfigureerd, geeft het gecentraliseerde DNS-systeem een lijst met IP-adressen, waarvan de volgorde is gebaseerd op de locatie van de client (gebruiker). In ons voorbeeld krijgt een gebruiker in Parijs die http://connect.example.com invoert, de volgende lijst 10.7.95.12, 10.7.145.11, 10.7.215.10 (Parijs, Tokio, Chicago), een gebruiker in Tokio krijgt de lijst 10.7.145.11, 10.7.95.12, 10.7.215.10 (Tokio, Parijs, Chicago), en elke andere gebruiker krijgt 10.7.215.10, 10.7.145.11, 10.7.95.12, (Chicago, Tokio, Parijs). Hiermee wordt het probleem voor Connect opgelost. Gebruikers in Parijs en Tokio worden nu via hun lokale Edge-servers geleid wanneer ze Connect openen, en alle anderen gaan rechtstreeks naar de Origin-server.
Als het DNS-systeem niet 'gecentraliseerd' is, als de DNS-servers de toewijzingstabel dus niet delen, dan is 'prioriteitstelling voor subnetten' niet nodig: elke DNS-server kan afzonderlijk worden geconfigureerd.
Op de Microsoft-website vindt u informatie over hoe u 'prioriteitstelling voor subnetten' kunt configureren.
Er zijn twee problemen waarvan u zich bewust moet zijn:
-
Als de client probeert connect.example.com om te zetten en er is geen DNS-vermelding voor het subnet van die client, dan wordt bij het weergeven van het IP-adres aan de client, de laatste DNS-vermelding die in de DNS-database/-tabel is ingevoerd als de eerst in aanmerking komende in de DNS-cache van de client geplaatst. Als een Edge-server dus is toegevoegd nadat DNS is geconfigureerd voor een implementatie met enkel Origin (zoals in dit voorbeeld), moet de DNS-vermelding voor de Origin worden verwijderd en opnieuw worden toegevoegd zodat het de laatste vermelding is.
-
Er is een klein probleem met de manier waarop 'prioriteitstelling voor subnetten' omgaat met het subnetmasker en netwerkklasse. De DNS-servers moeten Windows 2003-servers zijn en 'round robin' moet zijn uitgeschakeld. Zie het ondersteuningsartikel van Microsoft, http://support.microsoft.com/kb/842197.