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

Cet article décrit quelques principes 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 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 la façon de paramétrer et de configurer 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 des 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 des données sont demandées, elles sont mises en cache dans la mémoire. Par conséquent, il est normal de voir LSASS utiliser 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, la banque de versions ESE et d’autres. La suite de cet article donne 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 n’est limitée que par la RAM physique installée sur l’ordinateur. Tant qu’il n’existe aucune autre sollicitation de la 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

La banque de versions ESE (la partie rouge du diagramme ci-dessus) utilise la mémoire de manière variable. La quantité de mémoire utilisée varie si vous disposez de Windows Server 2019 ou versions antérieures de Windows.

• Dans les versions de Windows Server antérieures à Windows Server 2019, par défaut, LSASS peut utiliser jusqu’à environ 400 Mo de mémoire (en fonction du nombre de processeurs) sur un ordinateur 64 bits pour la banque 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 da la banque de versions ESE est désormais calculée sous la forme de 10 % de la 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.

Autre utilisation 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.

Limiter ou réduire le nombre de programmes sur votre contrôleur de domaine OU ajouter de la 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 d’autres processus qui peuvent s’exécuter sur un ordinateur. Liste des programmes à surveiller pour inclure 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 informations 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. En l’absence de demandes de mémoire, LSASS utilise cette mémoire pour mettre en cache la base de données Active Directory et par conséquent 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. Ils peuvent contenir des problèmes à résoudre. Ils peuvent inclure des composants Microsoft. Veillez à suivre les mises à jour de maintenance récentes : Microsoft inclut des solutions d’utilisation excessive de la mémoire dans le cadre des mises à jour de qualité, ce qui peut également améliorer les performances de votre 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 de 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 peu coûteuse à exécuter. Il s’agit souvent du volume d’appels qui entraînent une certaine surcharge, en particulier lorsque les solutions de supervision extraient de nouveaux événements à partir des différents journaux d’événements que Windows gère.

  Le journal d’ événements qui produit le plus de volume est généralement le journal d’é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.