Considerazioni su LDAP nell'ottimizzazione delle prestazioni di ADDS

  • Articolo

Importante

Di seguito è riportato un riepilogo delle raccomandazioni e delle considerazioni principali per ottimizzare l'hardware del server per i carichi di lavoro di Active Directory trattati in modo più approfondito nell'articolo Pianificazione della capacità per Active Directory Domain Services. I lettori sono invitati a consultare Pianificazione della capacità per Active Directory Domain Services per una maggiore comprensione tecnica e implicazioni di queste raccomandazioni.

Verificare le query LDAP

Verificare che le query LDAP siano conformi alle raccomandazioni per la creazione di query efficienti.

In MSDN è disponibile una documentazione completa su come scrivere, strutturare e analizzare correttamente le query da usare in Active Directory. Per maggiori informazioni, vedere Creazione di applicazioni abilitate per Microsoft Active Directory più efficienti.

Ottimizzare le dimensioni delle pagine LDAP

Quando si restituiscono risultati con più oggetti in risposta alle richieste client, il controller di dominio deve archiviare temporaneamente il set di risultati in memoria. L'aumento delle dimensioni delle pagine causerà un maggiore utilizzo della memoria e può estrarne gli elementi dalla cache inutilmente. In questo caso, le impostazioni predefinite sono ottimali. Esistono diversi scenari in cui sono stati eseguite raccomandazioni per aumentare le impostazioni delle dimensioni della pagina. È consigliabile usare i valori predefiniti, a meno che non siano identificati in modo specifico come inadeguati.

Quando le query hanno molti risultati, è possibile che venga rilevato un limite di query simili eseguite contemporaneamente. Ciò si verifica quando il server LDAP può esaurire un'area di memoria globale, nota come pool di cookie. Potrebbe essere necessario aumentare le dimensioni del pool, come illustrato in Come vengono gestiti i cookie del server LDAP.

Per ottimizzare queste impostazioni, vedere Windows Server 2008 e controller di dominio più recente restituisce solo 5000 valori in una risposta LDAP.

Determinare se aggiungere indici

L'indicizzazione degli attributi è utile durante la ricerca di oggetti con il nome dell'attributo in un filtro. L'indicizzazione può ridurre il numero di oggetti che deve essere visitato durante la valutazione del filtro. Tuttavia, ciò riduce le prestazioni delle operazioni di scrittura perché l'indice deve essere aggiornato quando l'attributo corrispondente viene modificato o aggiunto. Aumenta anche le dimensioni del database di directory, anche se i vantaggi spesso superano il costo dell'archiviazione. La registrazione può essere usata per trovare le query costose e inefficienti. Una volta identificate, valutare la possibilità di indicizzare alcuni attributi usati nelle query corrispondenti per migliorare le prestazioni di ricerca. Per altre info sul funzionamento delle ricerche di Active Directory, vedere Funzionamento delle ricerche di Active Directory.

Scenari che traggono vantaggio dall'aggiunta di indici

  • Il carico del client nella richiesta dei dati genera un utilizzo significativo della CPU e il comportamento della query client non può essere modificato o ottimizzato.

  • Il carico client genera operazioni di I/O significative su disco in un server a causa di un attributo non indicizzato e il comportamento della query client non può essere modificato o ottimizzato.

  • Una query richiede molto tempo e non viene completata in un intervallo di tempo accettabile per il client a causa della mancanza di indici di copertura.

  • Grandi volumi di query con durate elevate causano l'utilizzo e l'esaurimento dei thread LDAP ATQ. Monitora i dati dei contatori delle prestazioni seguenti

    • NTDS\Latenza di richiesta: è soggetto al tempo necessario per l'elaborazione della richiesta. Active Directory mette in timeout le richieste dopo 120 secondi (impostazione predefinita), ma la maggior parte delle query dovrebbe essere eseguita molto più velocemente. Le query con esecuzione estremamente lunga dovrebbero essere nascoste nei numeri complessivi. Cercare le modifiche apportate a questa baseline, anziché soglie assolute.

      Nota

      I valori elevati possono anche essere indicatori di ritardi nelle richieste di "proxying" ad altri domini e controlli CRL.

    • NTDS\Ritardo di coda stimato: in teoria dovrebbe essere quasi 0 per ottenere prestazioni ottimali. Ciò significa che le richieste non impiegano tempo in attesa di essere gestite.

Questi scenari possono essere rilevati usando uno o più degli approcci seguenti:

Altre considerazioni sull'indice

  • Assicurarsi che la creazione dell'indice sia la soluzione corretta al problema dopo che l'ottimizzazione della query è stata esaurita come opzione. Il dimensionamento corretto dell'hardware è molto importante. Gli indici devono essere aggiunti solo quando la correzione corretta consiste nell'indicizzare l'attributo e non nel tentativo di offuscare i problemi hardware.

  • Gli indici aumentano le dimensioni del database in base alla dimensione totale dell'attributo indicizzato. Una stima dell'aumento del database può quindi essere valutata prendendo le dimensioni medie dei dati nell'attributo e moltiplicando per il numero di oggetti che avranno l'attributo popolato. In genere si tratta di un aumento dell'1% delle dimensioni del database. Per altre info, vedi Funzionamento dell'archivio dati.

  • Se il comportamento di ricerca viene eseguito principalmente a livello di unità organizzativa, valutare la possibilità di indicizzare le ricerche in contenitori.

  • Gli indici di tupla sono più grandi degli indici normali, ma è molto più difficile stimare le dimensioni. Usare le stime delle dimensioni degli indici normali come piano per la crescita, con un massimo del 20%. Per altre info, vedi Funzionamento dell'archivio dati.

  • Se il comportamento di ricerca viene eseguito principalmente a livello di unità organizzativa, valutare la possibilità di indicizzare le ricerche in contenitori.

  • Gli indici di tupla sono necessari per supportare stringhe di ricerca mediali e stringhe di ricerca finali. Gli indici di tupla non sono necessari per le stringhe di ricerca iniziali.

    • Stringa di ricerca iniziale: (samAccountName=MYPC*)

    • Stringa di ricerca mediale: (samAccountName=*MYPC*)

    • Stringa di ricerca finale: (samAccountName=*MYPC$)

  • La creazione di un indice genererà l'I/O del disco durante la compilazione dell'indice. Questa operazione viene eseguita in un thread in background con priorità più bassa e le richieste in ingresso verranno classificate in ordine di priorità rispetto alla compilazione dell'indice. Se la pianificazione della capacità per l'ambiente è stata eseguita correttamente, dovrebbe essere trasparente. Tuttavia, gli scenari con elevato utilizzo di scrittura o un ambiente in cui il carico nell'archiviazione del controller di dominio è sconosciuto potrebbe compromettere l'esperienza client e deve essere eseguito fuori orario di minore attività.

  • L'impatto sul traffico di replica è minimo perché gli indici di compilazione si verificano localmente.

Per altre info, vedi quanto segue:

Riferimenti aggiuntivi