Considerazioni sull'utilizzo della memoria per l'ottimizzazione delle prestazioni di Active Directory Domain Services

In questo articolo vengono descritte alcune nozioni di base sul servizio di autorità di protezione locale (LSASS, noto anche come processo Lsass.exe), le procedure consigliate per la configurazione di LSASS e le aspettative sull'utilizzo della memoria. Questo articolo deve essere utilizzato come guida per l'analisi delle prestazioni di LSASS e per l'uso della memoria nei controller di dominio. Le informazioni contenute in questo articolo possono essere utili nel caso di domande su come sintonizzare e configurare i server e i controlli di dominio per ottimizzare questo motore.

LSASS è responsabile della gestione dell'autenticazione del dominio dell'autorità di protezione locale (LSA) e della gestione di Active Directory. LSASS gestisce l'autenticazione sia per il client che per il server e gestisce anche il motore di Active Directory. LSASS è responsabile dei seguenti componenti:

• Autorità di protezione locale
• Servizio NetLogon
• Servizio di gestione account di sicurezza (SAM)
• Servizio server LSA
• SSL (Secure Sockets Layer)
• Protocollo di autenticazione Kerberos v5
• Protocollo di autenticazione NTLM
• Altri pacchetti di autenticazione che vengono caricati in LSA

I servizi di database di Active Directory (NTDSAI.dll) funzionano con Extensible Storage Engine (ESE, ESENT.dll).

Di seguito è riportato un diagramma che mostra l'utilizzo della memoria di LSASS in un controllo di dominio:

La quantità di memoria usata da LSASS in un controller di dominio aumenta in base all'utilizzo di Active Directory. Quando i dati vengono sottoposti a query, vengono memorizzati nella cache di memoria. Di conseguenza, è normale che LSASS utilizzi una quantità di memoria superiore rispetto alle dimensioni del file di database di Active Directory (NTDS.dit).

Come illustrato nel diagramma, l'utilizzo della memoria di LSASS può essere suddiviso in diverse parti, tra cui la cache del buffer del database ESE, l'archivio delle versioni ESE e altro ancora. Il resto di questo articolo fornisce informazioni dettagliate su ognuna di queste parti.

Cache del buffer del database ESE

La cache del buffer del database ESE rappresenta il principale utilizzo di memoria variabile all'interno di LSASS. Le dimensioni della cache possono variare da meno di 1 MB per arrivare alle dimensioni dell'intero database. Dal momento che una cache più ampia potenzia le prestazioni, il motore del database per Active Directory (ESENT) mira a mantenere la cache quanto più grande possibile. Anche se le dimensioni della cache variano a seconda della pressione sulla memoria nel computer, le dimensioni massime della cache del buffer del database ESE sono limitate solo dalla RAM fisica installata nel computer. Finché non ci sono altre pressioni sulla memoria, la cache può raggiungere le dimensioni del file di database NTDS.dit di Active Directory. Maggiore è la quantità di database che può essere memorizzata nella cache, migliori saranno le prestazioni del controller di dominio.

Archivio delle versioni ESE

L'utilizzo della memoria da parte dell'archivio delle versioni ESE (la parte rossa nel diagramma precedente) è variabile. La quantità di memoria utilizzata dipende dalla presenza di Windows Server 2019 o di versioni precedenti di Windows.

• Nelle versioni di Windows Server precedenti a Windows Server 2019, per impostazione predefinita LSASS può utilizzare fino a circa 400 MB di memoria (a seconda del numero di CPU) in un computer a 64 bit per l'archivio della versione ESE. Per altre informazioni sull'uso dell'archivio delle versioni, vedere il post di blog ASKDS (Ask the Directory Services Team) seguente di Ryan Ries: The Version Store Called e They're All Out of Buckets.

• Windows Server 2019 semplifica questo aspetto, in modo che quando il servizio NTDS viene avviato per la prima volta, le dimensioni dell'archivio della versione ESE sono calcolate sulla base del 10% della RAM fisica, con un minimo di 400 MB e un massimo di 4 GB. Per informazioni dettagliate sulla risoluzione dei problemi relativi a questo archivio della versione, vedere un altro post di blog di Ryan Ries: Deep Dive: Active Directory ESE Version Store Changes in Server 2019.

Altri utilizzi di memoria

Infine, ci sono codice, stack, heap e varie strutture di dati a dimensione fissa (per esempio, la cache dello schema). La quantità di memoria usata da LSASS può variare a seconda del carico del computer. Con l'aumentare del numero di thread in esecuzione, aumenta anche il numero di stack di memoria. In media, LSASS usa da 100 MB a 300 MB di memoria per questi componenti fissi. Quando viene installata una quantità maggiore di RAM, LSASS può usare più RAM e meno memoria virtuale.

Limitare o ridurre al minimo il numero di programmi nel controller di dominio OPPURE aggiungere ulteriore RAM, se necessario

Per prestazioni ottimali, LSASS impiega il maggior numero di RAM possibile in un determinato controller di dominio. LSASS cede la RAM quando altri processi la richiedono. L'idea è quella di ottimizzare le prestazioni di LSASS tenendo conto degli altri processi in esecuzione sul computer. L'elenco dei programmi da controllare include gli agenti di monitoraggio. Alcuni clienti hanno agenti separati per varie funzioni del server che possono usare notevoli risorse di RAM. Alcuni possono emettere molte query WMI, per le quali vengono forniti alcuni dettagli di seguito.

Per questo motivo e per migliorare le prestazioni, è consigliabile limitare o ridurre al minimo il numero di programmi in un controller di dominio. Se non sono presenti richieste di memoria, LSASS usa questa memoria per memorizzare nella cache il database di Active Directory e quindi ottenere prestazioni ottimali.

In presenza di problemi relativi alle prestazioni di un controller di dominio, è fondamentale monitorare anche i processi che consumano significative quantità di memoria. Potrebbero verificarsi problemi che è necessario risolvere. Possono includere componenti Microsoft. Assicurarsi di essere al passo con i recenti aggiornamenti dell'assistenza: Microsoft include soluzioni per l'utilizzo eccessivo della memoria come parte degli aggiornamenti di qualità, che possono anche favorire le prestazioni del controller di dominio.

Esistono funzionalità predefinite del sistema operativo che possono utilizzare una quantità significativa di RAM, a seconda del profilo di utilizzo:

• File server. I controller di dominio fungono anche da file server per le condivisioni SYSVOL e Netlogon, fornendo criteri di gruppo e script per i criteri e gli script di avvio/accesso. Tuttavia, spesso che i clienti usano i controller di dominio per gestire altri tipi di contenuti del file. Il file server SMB utilizza la RAM per tenere traccia dei client attivi e, ancora più rilevante, il contenuto del file incrementa la cache del sistema operativo, entrando in competizione con la cache del database ESE per l'uso della RAM.

• Query WMI. Le soluzioni di monitoraggio spesso eseguono molte query WMI. L'esecuzione di una singola query può risultare conveniente. Spesso è il volume delle chiamate a creare un certo sovraccarico, in particolare quando le soluzioni di monitoraggio prelevano nuovi eventi dai diversi registri eventi gestiti da Windows.

  Il registro eventi che produce il maggior volume è in genere il registro eventi di sicurezza. Questo è anche il registro eventi che gli amministratori della sicurezza vogliono raccogliere, soprattutto dai controller di dominio.

  Il servizio WMI usa uno schema di allocazione di memoria dinamica che ottimizza le query. Pertanto, il servizio WMI potrebbe allocare molta memoria, anche in questo caso in competizione con la cache del database ESE.