Opzione di configurazione DNS per i server Adobe Connect Edge

Cerca

Ultimo aggiornamento il 18 gen 2022 | Si applica anche a Adobe Connect 9

Problema

Questa nota tecnica è destinata ad essere utilizzata come supplemento alla guida all'installazione e alla configurazione di Adobe Connect Enterprise Server 6.

I server periferici aggregano i dati in una posizione remota, creano pacchetti di ciò che non sono in grado di gestire e li passano a un server di origine. Affinché un server periferico possa fare il proprio lavoro, è necessario configurare correttamente il server DNS nelle posizioni remote.

Prendiamo in considerazione l’implementazione del server periferico di cui sopra in Example Co. Il server di origine è stato installato per qualche tempo a Chicago e gli utenti di Tokyo e Parigi, nonché di altre località su scala globale, lo hanno utilizzato in ambienti di produzione. Ci sono molti utenti Connect a Tokyo e Parigi e, per questo motivo, si è deciso di installare un server periferico in queste città.

Nome di dominio completo (FQDN)	Tipo	Indirizzo 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

Nota: i nomi di dominio e gli indirizzi IP riportati sopra sono solo esempi.

Prima dell'implementazione del server periferico (Edge), un utente di Tokyo, Parigi, Chicago o di qualsiasi altra località in Example Co. apriva un browser e inseriva l'URL http://connect.example.com per avviare una sessione Connect. C'era (e c'è ancora) un server DNS a Chicago, Parigi e Tokyo, così come in altre località che condividono le stesse mappature DNS. Una struttura DNS come questa è chiamata “sistema DNS centralizzato”. Poiché il sistema DNS è “centralizzato”, condividono tutti la stessa tabella di mappatura; pertanto, indipendentemente dalla posizione di un utente, connect.example.com si risolve in 10.7.215.10. Sfortunatamente, questo crea un problema una volta che i server periferici sono installati.

Dopo aver installato i server periferici, un utente di Tokyo deve essere mappato a 10.7.145.11 (edge.tokyo.example.com) quando inserisce http://connect.example.com, non a 10.7.215.10 (connect.example.com), mentre un utente di Parigi deve essere indirizzato a 10.7.95.12. Come è possibile configurare tutto ciò se un sistema DNS centralizzato condivide la stessa tabella di mappatura (connect.example.com rimanda sempre a 10.7.215.10 indipendentemente dalla posizione dell’utente)? La risposta è l’utilizzo della “prioritizzazione della subnet”.

Soluzione

Configurando la “prioritizzazione della subnet”, il sistema DNS centralizzato restituisce un elenco di indirizzi IP, il cui ordine è basato sulla posizione del client (utente). Quindi, nel nostro esempio, un utente di Parigi che accede a http://connect.example.com ottiene un elenco simile a 10.7.95.12, 10.7.145.11, 10.7.215.10 (Parigi, Tokyo, Chicago), un utente di Tokyo ottiene un elenco simile a 10.7.145.11, 10.7.95.12, 10.7.215.10 (Tokyo, Parigi, Chicago) e qualsiasi altro utente ottiene 10.7.215.10, 10.7.145.11, 10.7.95.12, (Chicago, Tokyo, Parigi). Questo risolve il problema di Connect. Ora gli utenti di Parigi e Tokyo vengono indirizzati attraverso i server periferici locali quando accedono a Connect e tutti gli altri utenti passano direttamente al server di origine.

Se il sistema DNS non è “centralizzato”, il che significa che i server DNS non condividono la tabella di mappatura, allora la “prioritizzazione della subnet” non è necessaria: ogni server DNS può essere configurato singolarmente.

Puoi trovare informazioni su come configurare la “prioritizzazione della subnet” sul sito Web di Microsoft.

Due sono le questioni da considerare:

Se il client tenta di risolvere connect.example.com e non è presente una voce DNS per la subnet del client, quando restituisce gli indirizzi IP al client, l’ultima voce DNS viene inserita nella tabella/nel database DNS come prima della cache DNS del client. Quindi, se un server periferico viene aggiunto dopo che il sistema DNS è stato configurato per l’implementazione solo di origine (come nel caso di questo esempio), la voce DNS per l’origine deve essere eliminata e riaggiunta affinché sia l’ultima voce.
C’è un piccolo problema su come la “prioritizzazione della subnet” gestisce la subnet mask e la classe di rete. I server DNS devono essere server Windows 2003 e “round robin” deve essere disattivato. Consulta l’articolo del supporto Microsoft, http://support.microsoft.com/kb/842197.