Condividi tramite

Esatto posizionamento dei controller di dominio e considerazioni sul sito

  • Articolo

La definizione corretta del sito è fondamentale per le prestazioni. I client che escono dal sito possono riscontrare prestazioni scarse per le autenticazioni e le query. Inoltre, con l'introduzione di IPv6 nei client, la richiesta può provenire dall'indirizzo IPv4 o dall'indirizzo IPv6 e Active Directory deve avere siti definiti correttamente per IPv6. Il sistema operativo preferisce IPv6 a IPv4 quando entrambi sono configurati.

A partire da Windows Server 2008, il controller di dominio tenta di usare la risoluzione dei nomi eseguendo una ricerca inversa per determinare il sito in cui dovrebbe trovarsi il client. Ciò può causare l'esaurimento del pool di thread ATQ e la mancata risposta del controller di dominio. La risoluzione appropriata consiste nel definire correttamente la topologia del sito per IPv6. Come soluzione alternativa, è possibile ottimizzare l'infrastruttura di risoluzione dei nomi per rispondere rapidamente alle richieste del controller di dominio. Per ulteriori informazioni, vedere Ritardo nella risposta del controller di dominio Windows Server 2008 o Windows Server 2008 R2 alle richieste LDAP o Kerberos.

Un'ulteriore area di considerazione consiste nella localizzazione di controller di dominio di lettura/scrittura per scenari in cui sono in uso controller di dominio di sola lettura. Alcune operazioni richiedono l'accesso a un controller di dominio scrivibile o sono destinate a un controller di dominio scrivibile quando sarebbe sufficiente un controller di dominio di sola lettura. L'ottimizzazione di questi scenari può seguire due percorsi:

  • Contattare i controller di dominio scrivibili quando sarebbe sufficiente un controller di dominio di sola lettura. Ciò richiede modifiche al codice dell'applicazione.
  • Dove potrebbe essere necessario un controller di dominio scrivibile. Situare controller di dominio di lettura/scrittura in posizioni centrali per ridurre al minimo la latenza.

Per altre informazioni di riferimento:

Ottimizzare per le segnalazioni

Le segnalazioni sono il modo in cui le query LDAP vengono reindirizzate quando il controller di dominio non ospita una copia della partizione sottoposta a query. Quando viene generata una segnalazione, questa contiene il nome distinto della partizione, un nome DNS e un numero di porta. Il client usa queste informazioni per continuare la query in un server che ospita la partizione. Si tratta di uno scenario DCLocator e vengono mantenute tutte le definizioni dei siti consigliate e il posizionamento del controller di dominio, ma le applicazioni che dipendono dalle segnalazioni spesso vengono trascurate. È consigliabile accertarsi che la topologia di Active Directory, incluse le definizioni del sito e il posizionamento del controller di dominio riflettano correttamente le esigenze del client. Ciò può includere anche la presenza di controller di dominio da più domini in un unico sito, l'ottimizzazione delle impostazioni DNS o la rilocazione del sito di un'applicazione.

Considerazioni sull'ottimizzazione per i trust

In uno scenario all'interno della foresta, i trust vengono elaborati in base alla gerarchia di dominio seguente: Dominio figlio maggiore -> Dominio figlio -> Dominio radice foresta -> Dominio figlio -> Dominio figlio maggiore. Ciò significa che i canali protetti nella radice della foresta e ogni elemento parent possono diventare sovraccarichi a causa dell'aggregazione delle richieste di autenticazione che transitano dai controller di dominio nella gerarchia dei trust. Inoltre, ciò può comportare dei ritardi nelle Active Directory a grande dispersione geografica quando l'autenticazione deve anche transitare su collegamenti altamente latenti per influire sul flusso precedente. Overload possono verificarsi in scenari di trust tra foreste e di livello inferiore. I consigli seguenti si applicano a tutti gli scenari:

  • Ottimizzare correttamente l'API MaxConcurrent per supportare il carico attraverso il canale protetto. Per ulteriori informazioni, vedere Come ottimizzare le prestazioni per l'autenticazione NTLM tramite l'impostazione MaxConcurrentApi.

  • Creare i trust di scelta rapida in base al carico.

  • Accertarsi che ogni controller di dominio nel dominio sia in grado di eseguire la risoluzione dei nomi e comunicare con i controller di dominio nel dominio trusted.

  • Accertarsi che vengano prese in considerazione le considerazioni sulla località per i trust.

  • Abilitare Kerberos laddove possibile e ridurre al minimo l'uso del canale sicuro per ridurre il rischio di incorrere in colli di bottiglia maxConcurrentAPI.

Gli scenari di trust tra domini sono un’area che ha costantemente rappresentato un punto dolente per molti client. La risoluzione dei nomi e i problemi di connettività, spesso dovuti ai firewall, causano l'esaurimento delle risorse nel controller di dominio trusting e influiscono su tutti i client. Inoltre, uno scenario spesso trascurato sta ottimizzando l'accesso ai controller di dominio trusted. Le aree chiave per garantire il corretto funzionamento sono le seguenti:

  • Accertarsi che la risoluzione dei nomi DNS e WINS usata dai controller di dominio trusting sia in grado di determinare un elenco preciso di controller di dominio per il dominio attendibile.

    • I record aggiunti in modo statico hanno la tendenza a diventare obsoleti e a rigenerare nel tempo problemi di connettività. I server d'inoltro DNS, IL DNS dinamico e l'unione di infrastrutture WINS/DNS sono più gestibili a lungo termine.

    • Garantire la corretta configurazione di server d'inoltro, inoltro condizionale e copie secondarie per le zone di ricerca diretta e quelle di ricerca inversa per ogni risorsa nell'ambiente in cui potrebbe dover accedere un client. Anche questo richiede manutenzione manuale e ha la tendenza a diventare obsoleto. Il consolidamento delle infrastrutture è ideale.

  • I controller di dominio nel dominio attendibile tenteranno prima di localizzare i controller di dominio nel dominio attendibile che si trovano nello stesso sito e poi di eseguire il failback nei localizzatori generici.

    • Per ulteriori informazioni sul funzionamento di DCLocator, vedere Ricerca di un controller di dominio nel sito più vicino.

    • Eseguire la convergenza dei nomi dei siti tra il dominio trusted e il dominio trusting per riflettere il controller di dominio nella stessa posizione. Verificare che le mappature della subnet e dell’indirizzo IP siano collegate correttamente ai siti in entrambe le foreste. Per ulteriori informazioni, vedere Localizzatore di domini in un trust tra foreste.

    • Accertarsi che le porte siano aperte, in base alle esigenze di DCLocator, per la posizione del controller di dominio. Se esistono firewall tra i domini, accertarsi che i firewall siano configurati correttamente per TUTTI i trust. Se i firewall non sono aperti, il controller di dominio trusting tenterà comunque di accedere al dominio trusted. Se per qualsiasi motivo la comunicazione non va a buon fine, il controller di dominio trusting potrebbe mandare in timeout la richiesta al controller di dominio trusted. Tuttavia, questi timeout possono richiedere diversi secondi per richiesta e possono esaurire le porte di rete nel controller di dominio trusting se il volume delle richieste in ingresso è elevato. Il client potrebbe percepire le attese del timeout nel controller di dominio come thread sospesi, il che potrebbe tradursi in applicazioni sospese (se l'applicazione esegue la richiesta nel thread in primo piano). Per ulteriori informazioni, vedere Configurazione di un firewall per domini e trust.

    • Usare DnsAvoidRegisterRecords per eliminare controller di dominio con prestazioni scarse o ad alta latenza, come ad esempio quelli nei siti satellite, dalla pubblicità ai localizzatori generici. Per ulteriori informazioni, vedere Come ottimizzare la posizione di un controller di dominio o di un catalogo globale che si trova all'esterno del sito di un client.

      Nota

      Il numero massimo di controller di dominio che il client può utilizzare è circa 50. Questi devono essere i controller di dominio con capacità ottimale e massima del sito.

    • Prendere in considerazione l'inserimento di controller di dominio da domini trusted e trusting nella stessa posizione fisica.

Per tutti gli scenari di trust, le credenziali vengono instradate in base al dominio specificato nelle richieste di autenticazione. Questo vale anche per le query per le API LookupAccountName e LsaLookupNames (così come per altre, queste sono solo le API più utilizzate). Quando ai parametri di dominio per queste API viene associato un valore NULL, il controller di dominio tenterà di trovare il nome dell'account specificato in ciascun dominio trusted disponibile.

Riferimenti aggiuntivi