Condividi tramite

Posizionamento corretto dei controller di dominio e considerazioni sul sito

La definizione corretta del sito è fondamentale per le prestazioni. I client che perdono il contatto con il 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 per eseguire una ricerca inversa per determinare il sito in cui deve trovarsi il client. Ciò può causare l'esaurimento del pool di thread ATQ e causare 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 altre informazioni, vedi Windows Server 2008 o Windows Server 2008 R2 Domain Controller ha ritardato la risposta alle richieste LDAP o Kerberos.

Un'altra area da considerare consiste nell'individuare i controller di dominio di lettura/scrittura per scenari in cui sono in uso i 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 un controller di dominio Read-Only sarebbe sufficiente. L'ottimizzazione di questi scenari richiede due percorsi:

  • Contattare controller di dominio scrivibili quando sarebbe sufficiente un controller di dominio Read-Only. Ciò richiede una modifica del codice dell'applicazione.
  • Dove potrebbe essere necessario un controller di dominio scrivibile. Posizionare 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 restituita una segnalazione, 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 vengono spesso trascurate. È consigliabile assicurarsi che la topologia di Active Directory, incluse le definizioni del sito e il posizionamento del controller di dominio riflettano correttamente le esigenze del client. Può includere anche la presenza di controller di dominio da più domini in un singolo sito, l'ottimizzazione delle impostazioni DNS o la rilocazione del sito di un'applicazione.

Considerazioni sull'ottimizzazione per i trust

In uno scenario intra-foresta, i trust sono elaborati in base alla gerarchia di dominio seguente: Grand-Child Dominio -> Dominio figlio -> Dominio radice della foresta -> Dominio figlio -> Dominio Grand-Child. Ciò significa che i canali sicuri nella radice della foresta e ogni genitore possono diventare sovraccarichi a causa dell'aggregazione delle richieste di autenticazione che transitano attraverso i controller di dominio nella gerarchia di attendibilità. Ciò può anche comportare ritardi nelle Active Directory con grande dispersione geografica quando l'autenticazione deve transitare attraverso collegamenti ad alta latenza, influenzando così il flusso precedente. Sovraccarichi possono verificarsi in scenari di attendibilità tra foreste e di livello più basso. I consigli seguenti si applicano a tutti gli scenari:

  • Ottimizzare correttamente l'API MaxConcurrent per supportare il carico attraverso il canale protetto. Per altre informazioni, vedere Come eseguire l'ottimizzazione delle prestazioni per l'autenticazione NTLM usando l'impostazione MaxConcurrentApi.

  • Creare trust di scorciatoia come appropriato in base al carico.

  • Assicurarsi 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 attendibile.

  • Assicurarsi 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 diminuire il rischio di trovarsi nei colli di bottiglia di MaxConcurrentAPI.

Gli scenari di trust tra domini sono un'area che è stata costantemente un punto di dolore per molti clienti. La risoluzione dei nomi e i problemi di connettività, spesso dovuti ai firewall, causano l'esaurimento delle risorse nel controller di dominio attendibile e influiscono su tutti i client. Inoltre, uno scenario spesso trascurato è l'ottimizzazione dell'accesso ai controller di dominio attendibili. Le aree chiave per garantire il corretto funzionamento sono le seguenti:

  • Assicurarsi che la risoluzione dei nomi DNS e WINS usata dai controller di dominio attendibili possa risolvere un elenco accurato di controller di dominio per il dominio attendibile.

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

    • Assicurarsi della corretta configurazione di server di inoltro, inoltri condizionali e copie secondarie per le zone di ricerca diretta e inversa relative a ogni risorsa nell'ambiente a cui un client potrebbe aver bisogno di accedere. Anche in questo caso, ciò richiede manutenzione manuale e ha la tendenza a diventare obsoleto. Il consolidamento delle infrastrutture è ideale.

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

    • Per altre info sul funzionamento di DCLocator, vedi Ricerca di un controller di dominio nel sito più vicino.

    • Uniformare i nomi dei siti tra i domini fidati e fiduciosi per riflettere il controller di dominio nella stessa posizione. Verificare che le mappature di subnet e indirizzi IP siano collegate correttamente ai siti in entrambe le foreste. Per altre informazioni, vedi Localizzatore di domini in un trust tra foreste.

    • Assicurarsi che le porte siano aperte, in base alle esigenze di DCLocator, per la localizzazione del controller di dominio. Se esistono firewall tra i domini, assicurarsi che i firewall siano configurati correttamente per TUTTI i trust. Se i firewall non sono aperti, il controller di dominio attendibile tenterà comunque di accedere al dominio attendibile. Se la comunicazione fallisce per qualsiasi motivo, il controller di dominio fidato alla fine annullerà la richiesta al controller di dominio di fiducia. Tuttavia, questi timeout possono richiedere diversi secondi per richiesta e possono esaurire le porte di rete nel controller di dominio attendibile se il volume delle richieste in ingresso è elevato. Il client potrebbe riscontrare le attese che portano a un timeout nel controller di dominio come thread bloccati, il che potrebbe tradursi in applicazioni bloccate (se l'applicazione esegue la richiesta nel thread in primo piano). Per altre info, vedi Come configurare un firewall per domini e trust.

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

      Annotazioni

      Esiste un limite pratico di circa 50 al numero di controller di dominio che il client può utilizzare. Questi devono essere i controller di dominio con capacità massima e ottimale per il sito.

    • Prendere in considerazione l'inserimento di controller di dominio da domini attendibili e attendenti nella stessa ubicazione fisica.

Per tutti gli scenari di attendibilità, 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 altre, sono solo le API usate più di frequente). Quando i parametri di dominio per queste API vengono passati un valore NULL, il controller di dominio tenterà di trovare il nome dell'account specificato in ogni dominio attendibile disponibile.

Riferimenti aggiuntivi