Common Logging File System

Mit dem System.IO.Log-Namespace wird eine Schnittstelle zur Protokollierung eines datensatzorientierten sequenziellen E/A-Systems definiert. Unter Verwendung der Klassen aus diesem Namespace können Sie Ihr eigenes Diagnoseprotokollierungs- oder Transaktionsverarbeitungssystem implementieren. Der Namespace liefert außerdem eine Implementierung dieser Schnittstelle, die ein einfaches dateibasiertes Protokoll verwendet, sowie eine alternative Implementierung, die das von ws2003r2 und Windows Vista bereitgestellte Common Log File System (CLFS) verwendet.

System.IO.Log-Namespace

Mit dem System.IO.Log-Namespace wird eine Schnittstelle zur Protokollierung eines datensatzorientierten sequenziellen E/A-Systems definiert. Mit Implementierungen dieser Schnittstelle können Protokolldatensätze gelesen und geschrieben werden. Werden Protokolldatensätze an solch eine Implementierung angehängt, erhält jeder Protokolldatensatz eine eindeutige Sequenznummer. Sequenznummern nehmen innerhalb einer angegebenen Datensatzsequenz gleichmäßig zu. Nummern aus verschiedenen Datensatzsequenzen sind nicht vergleichbar. Sequenznummern werden mit der SequenceNumber-Struktur dargestellt. Darüber hinaus bietet die Datensatzsequenz einen Mechanismus zur Reservierung von Speicherplatz in dem zugrunde liegenden Speicher. Sie können diesen Reservierungsmechanismus nutzen, um sicherzustellen, dass für spätere Protokolldatensätze ausreichend Speicherplatz vorhanden ist.

Von der FileRecordSequence-Klasse und der LogRecordSequence-Klasse werden zwei verschiedene Implementierungen dieser Schnittstelle bereitgestellt. Die FileRecordSequence ist eine auf einer einzelnen Protokolldatei im Dateisystem basierende Datensatzsequenz.

Die LogRecordSequence-Klasse stellt dagegen eine Implementierung der Datensatzsequenzschnittstelle zusätzlich zu einem Common Log File System (CLFS)-Protokoll bereit. Weitere Informationen zu dieser Implementierung finden Sie im Abschnitt "System.IO.Log-Abstraktion".

CLFS

CLFS stellt einen äußerst leistungsfähigen, universell einsetzbaren Protokolldateidienst bereit, den dedizierte Client-Anwendungen verwenden und mehrere Clients gemeinsam nutzen können, um den Protokollzugriff zu optimieren.

Protokollarchitektur

Das CLFS ist ein ARIES-Protokollmanager. Protokolldatensätze werden in einer sequenziellen Reihenfolge gespeichert und können sicherstellen, dass weggeschriebene Protokolldatensätze erhalten bleiben, auch nach einem Systemabsturz. Mit CLFS können Sie Protokolle verwalten und Anwendungsrichtlinien festlegen. CLFS verwendet die folgenden Abstraktionen zur Implementierung von Protokollierung:

• Ein Datensatz ist eine von einem Client geschriebene Dateneinheit.

• Ein physisches Protokoll ist ein physischer Satz Dateien und Attribute, in denen einer oder mehrere Protokollstreams gespeichert sind. Ein Protokollstream ist eine Sequenz von einem Client protokollierter Protokolldatensätze. Er ist mit einem physischen Protokoll vergleichbar. Ein dediziertes Protokoll verfügt nur über einen unbenannten Stream. Ein Multiplexprotokoll verfügt über einen oder mehrere benannte Streams, und es können später mehrere Streams für ein Multiplexprotokoll erstellt werden. Ein Client kann in jedem beliebigen Protokolltyp einen oder mehrere Protokollstreams protokollieren. Nach der Erstellung kann ein Protokoll jedoch nicht mehr in einen anderen Typ konvertiert werden.

Ein Multiplexprotokoll stellt eine Vertragsvereinbarung zwischen zwei Anwendungen oder Subsystemen dar, die dasselbe Protokoll verwenden. Jeder Stream in einem Multiplexprotokoll wird dem Client-Eigentümer so angezeigt, als wäre er in einem dedizierten Protokoll gespeichert. Der Hauptvorteil der Verwendung eines Multiplexprotokolls besteht darin, dass die E/A-Kosten des Systems auf mehrere Streams aufgeteilt werden, sodass die Systemleistung möglicherweise besser ist als bei Verwendung mehrerer dedizierter Protokolle. Datensätze und Protokollblöcke in Multiplexprotokollen werden normalerweise in denselben Festplattenzylinder geschrieben, wodurch der Suchaufwand minimiert und die E/A-Latenz verringert werden.

Der Protokolldateizugriff kann entweder an eine lokale Festplatte oder über einen internen Client-Server-Support an Festplatten in Remotesystemen geleitet werden. In einem Cluster kann für Protokolldateien mit dem Standard-OS-Mechanismus ein Failover zu einem anderen System durchgeführt werden. Alle Schreibvorgänge in das Protokoll werden auf dem Client gepuffert, bis ein Wegschreibevorgang oder ein neuer Pufferspeicher erforderlich werden. Nach Möglichkeit werden Daten direkt aus den Clientpufferspeichern ohne Kopieren direkt auf die Festplatte geschrieben. Lesevorgänge werden zwischengespeichert, um die Festplattenzugriffe während Wiederherstellungsvorgängen, Sicherungen oder häufigeren Transaktionsabbrüchen zu verringern.

Das physische Protokoll wird tatsächlich als "base log file" (blf) (Basisprotokolldatei) gespeichert, das die Metadaten und eine beliebige Anzahl Containerdateien (oder Streams innerhalb einer Datei) enthält. Sie können angeben, ob Ihr Protokoll erstellt werden soll, und die Protokollcontainer direkt erstellen. Sie müssen mindestens zwei Container hinzufügen, damit das Protokoll verwendet werden kann. Protokollrichtlinien können jedoch ohne Container festgelegt werden.

System.IO.Log-Abstraktion

Die LogRecordSequence-Klasse stellt eine Implementierung der Datensatzsequenzschnittstelle auf einem CLFS-Protokoll (gemeinsames Protokolldateisystem) bereit. Zusätzlich zu den datensatzorientierten Standardfunktionen wird ein Richtlinienmodell zur Vermeidung von vollen Protokollen und von Multiplexing von Clients auf derselben physischen Datei bereitgestellt. Es arbeitet mit der LogStore-Klasse zusammen, die eine Schnittstelle für die direkte Bearbeitung und Verwaltung einer CLFS-Protokolldatei bereitstellt. Die Beziehung zwischen der LogStore-Klasse und der LogRecordSequence-Klasse ähnelt der Beziehung zwischen einer Datenträgerdatei und einem FileStream-Objekt. Die Datenträgerdatei stellt den tatsächlichen Speicherplatz bereit und weist Attribute wie die Länge und den letzten Zugriff auf, während das FileStream-Objekt eine Ansicht der Datei bereitstellt, über die Lese- und Schreibvorgänge für die Datei ausgeführt werden können. Ähnlich weist die LogStore-Klasse Attribute wie eine Richtlinie und eine Sammlung von Datenträgerwertebereichen auf, und die LogRecordSequence-Klasse bietet einen datensatzorientierten Mechanismus zum Lesen und Schreiben von Daten.

Anders als die Dateidatensatzsequenz, die von der FileRecordSequence-Klasse dargestellt wird, speichert eine LogStore-Instanz ihre Daten in einer Auflistung von Datenträgerwertebereichen, die von LogExtent-Instanzen dargestellt werden. Die Wertebereiche in einer bestimmten LogStore-Instanz weisen eine einheitliche Größe auf. Speicherplatz wird einer LogStore-Instanz in Wertebereichsschritten hinzugefügt oder daraus gelöscht.

Die tatsächlichen Protokolldatensätze werden durch Instanzen der LogRecord-Klasse dargestellt.

Richtlinie

Eine LogStore-Instanz kann zugeordnete Richtlinien aufweisen. Diese werden von LogPolicy-Instanzen dargestellt. Eine Richtlinie schreibt bestimmte Regeln vor, die das Protokoll zu befolgen versucht, beispielsweise die Maximal- und die Mindestanzahl an Wertebereichen oder Anweisungen zum Erweitern oder Verkleinern der LogStore unter bestimmten Bedingungen. Außerdem können Sie angeben, ob eine LogStore-Instanz archiviert werden kann oder nicht.

Richtlinien werden pro Protokoll festgelegt und sind flüchtig, das heißt, sobald jedes Handle für das Protokoll geschlossen wurde, existiert die Richtlinie nicht mehr.

Sicherheit

Ein Protokoll ist mit einer NTFS ACL (Zugriffskontrollliste) geschützt. Nach Möglichkeit sollte ein Protokoll nicht auf einem FAT-Datenträger gespeichert werden, da dort kein Schutz vorhanden ist.

Siehe auch

Konzepte

Einfaches Dateiprotokollsystem

Senden Sie Kommentare zu diesem Thema an Microsoft.

Copyright © 2007 by Microsoft Corporation. Alle Rechte vorbehalten.