Système de fichiers de journalisation courant

Article
04/22/2008

L'espace de noms System.IO.Log définit une interface pour la journalisation dans un système d'E/S séquentiel orienté par enregistrement. À l'aide des classes de cet espace de noms, vous pouvez implémenter votre propre journalisation de diagnostics ou système de traitement transactionnel. L'espace de noms fournit également une implémentation de cette interface qui utilise un journal simple basé sur des fichiers, ainsi qu'une autre implémentation qui utilise le système CLFS (Common Log File System) fourni par ws2003r2 et Windows Vista.

Espace de noms System.IO.Log

L'espace de noms System.IO.Log définit une interface pour la journalisation dans un système d'E/S séquentiel orienté par enregistrement. Les implémentations de cette interface peuvent être utilisées pour lire et écrire des enregistrements de journal. Lorsque des enregistrements de journal sont ajoutés à une telle implémentation, chacun d'entre eux reçoit un numéro de séquence unique. Les numéros de séquence augmentent de façon stricte et monotone dans une séquence d'enregistrement donnée et les nombres de différentes séquences d'enregistrements ne sont pas comparables. Les numéros de séquence sont représentés par la structure SequenceNumber. De plus, la séquence d'enregistrement fournit un mécanisme pour réserver de l'espace dans le stockage sous-jacent. Vous pouvez tirer parti de ce mécanisme de réservation pour garantir que l'espace nécessaire est suffisant pour les futurs enregistrements de journal.

Deux implémentations différentes de cette interface sont fournies par les classes FileRecordSequence et LogRecordSequence. La classe FileRecordSequence est une séquence d'enregistrement basée sur un fichier journal unique dans le système de fichiers.

La classe LogRecordSequence fournit, elle, une implémentation de l'interface de séquence d'enregistrement sur un journal CLFS (Common Log File System). Pour plus d'informations sur cette implémentation, consultez la section "Abstraction System.IO.Log".

CLFS

CLFS fournit un service de journal de fichiers hautes performances à usage général que les applications clientes dédiées peuvent utiliser et que plusieurs clients peuvent partager pour optimiser l'accès au journal.

Architecture du journal

Le CLFS est un gestionnaire de journaux ARIES. Il enregistre des enregistrements de journal dans un ordre séquentiel et peut s'assurer que les enregistrements de journal qui ont été vidés sont conservés, même après une défaillance du système. Vous pouvez utiliser CLFS pour gérer des journaux et définir une stratégie d'application. CLFS utilise les abstractions suivantes pour implémenter la journalisation :

Un enregistrement est une unité des données écrite par un client.
Un journal physique est un jeu physique de fichiers et d'attributs qui stockent un ou de nombreux flux de journal. Un flux de journal est une séquence d'enregistrements de journal consignée par un client. Il peut être comparé à un journal physique. Un journal dédié a un seul flux sans nom. Un journal multiplexé comporte un ou plusieurs flux nommés, et vous pouvez en créer davantage par la suite. Un client peut consigner un ou plusieurs flux de journal dans tout type de journal. Toutefois, dès qu'un journal a été créé, il ne peut pas être converti d'un type à un autre.

Un journal multiplexé représente un engagement contractuel entre deux applications ou sous-systèmes qui partagent le même journal. Chaque flux dans un journal multiplexé apparaît à son propriétaire client comme s'il était stocké dans un journal dédié. Le principal avantage de l'utilisation d'un journal multiplexé est que les coûts d'E/S du système sont partagés entre plusieurs flux ; par conséquent, les performances du système peuvent être supérieures par rapport à l'utilisation de plusieurs journaux dédiés. Les enregistrements et les blocs de journaux multiplexés sont généralement écrits dans le même cylindre de disque, ce qui réduit les temps d'accès et la latence d'E/S.

L'accès au fichier journal peut être dirigé vers un disque local ou vers des disques sur des systèmes distants via une prise en charge client-serveur interne. Dans un cluster, les fichiers journaux peuvent basculer vers un autre système à l'aide de mécanismes de système d'exploitation standard. Toutes les écritures dans le journal sont mises en mémoire tampon au niveau du client jusqu'à ce qu'un vidage ou qu'une nouvelle mémoire tampon soit requise. Lorsque cela est possible, les données sont écrites directement sur le disque depuis les mémoires tampon clientes sans copie. Les lectures sont mises en cache pour réduire l'accès au disque pendant les opérations de récupération, une sauvegarde ou des rafales d'abandons de transaction.

Le journal physique est en fait stocké comme un "fichier journal de base" (blf) qui conserve les métadonnées et le nombre de fichiers conteneurs (ou flux dans un fichier). Vous pouvez définir l'emplacement de création pour votre journal et créer les conteneurs de journal directement. Vous devez ajouter au moins deux conteneurs pour que le journal soit utilisable. Toutefois, les stratégies de journal peuvent être définies sans conteneur.

Abstraction System.IO.Log

La classe LogRecordSequence fournit une implémentation de l'interface de séquence d'enregistrement sur un journal CLFS (Common Log File System). Outre les fonctionnalités orientées par enregistrement standard, elle fournit un modèle de stratégie pour éviter des conditions de journal saturé et pour multiplexer des clients sur le même fichier physique. Elle fonctionne avec la classe LogStore qui fournit une interface pour manipuler et gérer directement un fichier journal CLFS. La relation entre la classe LogStore et la classe LogRecordSequence est similaire à la relation entre un fichier sur un disque et un objet FileStream. Le fichier sur disque fournit la mémoire physique et a des attributs tels que la longueur et le dernier temps d'accès, alors que l'objet FileStream fournit une vue sur le fichier qui peut être utilisée pour la lecture et l'écriture. De la même façon, la classe LogStore a des attributs tels qu'une stratégie et une collection d'étendues de disque, et la classe LogRecordSequence fournit un mécanisme orienté par enregistrement pour lire et écrire des données.

Contrairement à la séquence d'enregistrement de fichier représentée par la classe FileRecordSequence, une instance LogStore stocke ses données dans une collection d'étendues de disque, représentée par les instances LogExtent. Les étendues dans une instance LogStore donnée sont toutes de taille uniforme et l'espace est ajouté et supprimé d'une instance LogStore par incréments d'étendue.

Les enregistrements de journal proprement dits sont représentés par des instances de la classe LogRecord.

Stratégie

Des stratégies peuvent être associées à une instance LogStore. Celles-ci sont représentées par les instances LogPolicy. Une stratégie énonce les règles que le journal tente de suivre, tel que le nombre maximal d'étendues et la taille minimale, et fournit des instructions à propos de l'agrandissement ou de la réduction de la taille du LogStore sous certaines conditions. De plus, vous pouvez spécifier si une instance LogStore peut être archivée ou non.

Les stratégies sont définies par journal et ne sont pas rémanentes, ce qui signifie qu'une fois que chaque handle du journal est fermé, la stratégie n'existe plus.

Sécurité

Un journal est protégé par une ACL (liste de contrôle d'accès) NTFS standard. Il n'est pas recommandé de stocker un journal sur un lecteur FAT du fait de l'absence de protection.