Considérations relatives à l’utilisation de la mémoire pour le réglage des performances AD DS

Cet article décrit quelques notions de base du service de sous-système de l’autorité de sécurité locale (LSASS, également appelé processus de Lsass.exe), les meilleures pratiques pour la configuration de LSASS et les attentes en matière d’utilisation de la mémoire. Cet article doit être utilisé comme guide dans l’analyse des performances et de l’utilisation de la mémoire LSASS sur les contrôleurs de domaine (DCS). Les informations contenues dans cet article peuvent être utiles si vous avez des questions sur l’optimisation et la configuration des serveurs et des contrôleurs de domaine pour optimiser ce moteur.

LSASS est responsable de la gestion de l’authentification de domaine de l’autorité de sécurité locale (LSA) et de la gestion Active Directory. LSASS gère l’authentification pour le client et le serveur, et elle régit également le moteur Active Directory. LSASS est responsable des composants suivants :

• Autorité de sécurité locale
• Service NetLogon
• Service Gestionnaire de comptes de sécurité (SAM)
• Service serveur LSA
• SSL (Secure Sockets Layer)
• Protocole d’authentification Kerberos v5
• Protocole d’authentification NTLM
• Autres packages d’authentification qui se chargent dans LSA

Les services de base de données Active Directory (NTDSAI.dll) fonctionnent avec le moteur de stockage extensible (ESE, ESENT.dll).

Voici un diagramme visuel de l’utilisation de la mémoire LSASS sur un contrôleur de domaine :

La quantité de mémoire utilisée par LSASS sur un contrôleur de domaine augmente conformément à l’utilisation d’Active Directory. Lorsque les données sont interrogées, elles sont mises en cache en mémoire. Par conséquent, il est normal que LSASS utilise une quantité de mémoire supérieure à la taille du fichier de base de données Active Directory (NTDS.dit).

Comme illustré dans le diagramme, l’utilisation de la mémoire LSASS peut être divisée en plusieurs parties, notamment le cache de mémoire tampon de base de données ESE, le magasin de versions ESE et d’autres. Le reste de cet article fournit un aperçu de chacune de ces parties.

Cache de mémoire tampon de base de données ESE

La plus grande utilisation de la mémoire variable dans LSASS est le cache de mémoire tampon de base de données ESE. La taille du cache peut aller de moins de 1 Mo à la taille de la base de données entière. Étant donné qu’un cache plus volumineux améliore les performances, le moteur de base de données pour Active Directory (ESENT) tente de conserver le cache le plus grand possible. Bien que la taille du cache varie en fonction de la pression de la mémoire sur l’ordinateur, la taille maximale du cache de mémoire tampon de base de données ESE est limitée uniquement par la RAM physique installée sur l’ordinateur. Tant qu’il n’y a pas d’autre pression de mémoire, le cache peut atteindre la taille du fichier de base de données NTDS.dit Active Directory. Plus la base de données peut être mise en cache, plus les performances du contrôleur de domaine seront améliorées.

Banque de versions ESE

On observe une utilisation variable de la mémoire par le magasin de versions ESE (partie rouge du diagramme ci-dessus). La quantité de mémoire utilisée dépend de l’utilisation de Windows Server 2019 ou d’anciennes versions de Windows.

• Dans les versions de Windows Server antérieures à Windows Server 2019, par défaut, LSASS peut utiliser jusqu’à 400 Mo de mémoire (selon le nombre de processeurs) sur une machine 64 bits pour le magasin de versions ESE. Pour plus d’informations sur la façon dont la banque de versions est utilisé, consultez le billet de blog ASKDS de Ryan Ries: The Version Store Called and They’re All Out of Buckets.

• Dans Windows Server 2019, cela est simplifié et lorsque le service NTDS démarre pour la première fois, la taille du magasin de versions ESE est désormais calculée en tant que 10% de RAM physique, avec un minimum de 400 Mo et un maximum de 4 Go. Pour plus d’informations sur ce problème et la résolution des problèmes liés à la banque de versions, consultez un autre excellent blog de Ryan Ries: Deep Dive: Active Directory ESE Versions Store Changes in Server 2019.

Autres utilisations de la mémoire

Enfin, il existe du code, des piles, des tas et diverses structures de données de taille fixe (par exemple, le cache de schéma). La quantité de mémoire utilisée par LSASS peut varier en fonction de la charge sur l’ordinateur. À mesure que le nombre de threads en cours d’exécution augmente, le nombre de piles de mémoire augmente. En moyenne, LSASS utilise 100 Mo à 300 Mo de mémoire pour ces composants fixes. Lorsqu’une plus grande quantité de RAM est installée, LSASS peut utiliser plus de RAM et moins de mémoire virtuelle.

Limitez ou réduisez le nombre de programmes sur votre contrôleur de domaine OU ajoutez une RAM supplémentaire le cas échéant

Pour des performances optimales, LSASS prend autant de RAM que possible sur un contrôleur de domaine donné. LSASS abandonne cette RAM comme d’autres processus lui demandent. L’idée est d’optimiser les performances de LSASS tout en tenant compte des autres processus qui peuvent s’exécuter sur un ordinateur. La liste des programmes à surveiller comprend des agents de surveillance. Certains clients ont des agents distincts pour différentes fonctions serveur qui peuvent consommer des ressources ram considérables. Certains peuvent émettre de nombreuses requêtes WMI, pour lesquelles nous avons quelques détails ci-dessous.

Pour cette raison et pour augmenter les performances, il est recommandé de limiter ou de réduire le nombre de programmes sur un contrôleur de domaine. S’il n’existe aucune demande de mémoire, LSASS utilise cette mémoire pour mettre en cache la base de données Active Directory et ainsi obtenir des performances optimales.

Lorsque vous remarquez qu’un contrôleur de domaine présente des problèmes de performances, surveillez également les processus avec une utilisation significative de la mémoire. Il peut s’agit d’un problème que vous devez résoudre. Ils peuvent inclure des composants Microsoft. Veillez à suivre les dernières mises à jour de maintenance : Microsoft inclut des solutions pour une utilisation excessive de la mémoire dans le cadre des mises à jour de qualité, ce qui peut également aider vos performances de contrôleur de domaine.

Il existe des installations de système d’exploitation intégrées qui peuvent consommer une ram importante en fonction du profil d’utilisation :

• Serveur de fichiers. Les contrôleurs de domaine sont également des serveurs de fichiers pour les partages SYSVOL et Netlogon, la stratégie de groupe de maintenance et les scripts pour les scripts de stratégie et de démarrage/ouverture de session. Toutefois, nous voyons que les clients utilisent des contrôleurs de domaine pour traiter d’autres contenus de fichiers. Le serveur de fichiers SMB consommerait ensuite la RAM pour suivre les clients actifs, mais avant tout, le contenu du fichier augmenterait le cache de fichiers du système d’exploitation et concurrencerait le cache de base de données ESE pour la RAM.

• Requêtes WMI. Les solutions de supervision effectuent souvent de nombreuses requêtes WMI. Une requête individuelle peut être bon marché à exécuter. Il s’agit souvent du volume d’appels qui entraînent une surcharge, en particulier lorsque les solutions de surveillance extraient de nouveaux événements à partir des différents journaux d’événements que Windows gère.

  Le journal des événements qui produit le plus de volume est généralement le journal des événements de sécurité. Il s’agit également du journal d’événements que les administrateurs de sécurité souhaitent collecter, en particulier à partir de contrôleurs de domaine.

  Le service WMI utilise un schéma d’allocation de mémoire dynamique qui optimise les requêtes. Par conséquent, le service WMI peut allouer beaucoup de mémoire, en concurrence avec le cache de base de données ESE.