> Tech > Modèles d’E/S et journaux de transactions

Modèles d’E/S et journaux de transactions

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

On a observé que 70 à  90 pour cent des opérations effectuées par AD sur ntds.dit sont des lectures. Ces chiffres n'ont rien de surprenant puisque la fonction première d'AD est l'authentification des utilisateurs, qui nécessite de contrôler les mots de passe contenus dans AD en les comparant aux références

Modèles d’E/S et journaux de transactions

fournies par l’utilisateur. Même une application comme Exchange 2000, qui place les informations dans AD, effectue plus de lectures que d’écritures puisqu’elle tend à  récupérer beaucoup plus d’informations qu’elle n’en met à  jour.
L’accès à  ntds.dit est multithread et asynchrone. En d’autres termes, beaucoup de threads s’exécutent en même temps pour prendre en charge les requêtes de différents clients et applications. Les opérations en écriture repassent immédiatement la main à  ESE, mais celui-ci peut très bien attendre un peu avant d’appliquer une mise à  jour à  la base de données.
Le système lit les fichiers-journaux uniquement à  l’occasion d’une opération de reprise logicielle ou matérielle, lorsqu’il faut réexécuter les transactions. Les écritures sont mono-thread et synchrones. Un seul thread contrôle toutes les écritures et il ne peut donc y avoir qu’une opération en écriture en cours à  la fois. Le thread appelant doit attendre qu’une écriture soit terminée avant de pouvoir avancer. AD accède séquentiellement aux fichiers-journaux et annexe les données à  la fin du journal en cours.
Lors de l’ajout, de la modification ou de la suppression d’un objet AD, le moteur de la base de données écrit d’abord la transaction dans une mémoires tampon, formant un cache en mémoire, puis saisit immédiatement la transaction dans le journal de transactions en cours (edb.log). Lorsque les deux opérations sont achevées, le système considère la transaction comme effectuée. Cette implémentation garantit que les données sont récupérables avant que le système ne tente de l’écrire dans ntds.dit.
Le processus LSA (Local Security Authority – lsass.exe) contrôle toutes les transactions d’AD. Lorsque la charge du système le permet, lsass.exe recherche dans le cache de la mémoire les pages non sauvegardées, les sauvegarde dans la base de données et déplace le pointeur du point de reprise pendant que le système sauvegarde les mémoires tampons. Si un système tombait en panne ou si un disque avait une défaillance à  ce moment-là , les données pourraient être récupérées dans les journaux de transactions.
Pour écrire dans ses bases de données et dans ses journaux de transactions, AD utilise exactement les mêmes principes qu’Exchange. Tout comme lui, il supporte la consignation circulaire et non-circulaire. Dans la consignation circulaire, le système recycle jusqu’à  20 journaux de transactions dans un jeu pour contenir les transactions. Dans la consignation non-circulaire, Exchange maintient un jeu complet de journaux de transactions jusqu’à  la suppression du jeu, une fois qu’une sauvegarde complète a été effectuée (idéalement, il faudrait effectuer des sauvegardes quotidiennement). Mais AD vide automatiquement les journaux de transactions toutes les 12 heures, contrairement à  ce qui se passe dans Exchange.

Téléchargez cette ressource

Les mégatendances cybersécurité et cyber protection 2024

Les mégatendances cybersécurité et cyber protection 2024

L'évolution du paysage des menaces et les conséquences sur votre infrastructure, vos outils de contrôles de sécurité IT existants. EPP, XDR, EDR, IA, découvrez la synthèse des conseils et recommandations à appliquer dans votre organisation.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010