Die externe FPolicy Engine identifiziert die externen FPolicy Server (FPolicy Server), die einer bestimmten FPolicy Konfiguration zugeordnet sind. Wenn die interne „nativ“ FPolicy Engine verwendet wird, um eine native Dateiblockierungskonfiguration zu erstellen, ist das Erstellen einer externen FPolicy Engine nicht erforderlich.

Ab ONTAP 9.15.1 kann das protobuf Engine-Format verwendet werden. Wenn auf protobuf gesetzt, werden die Benachrichtigungsnachrichten binär mit Google Protobuf codiert. Bevor das Engine-Format auf protobuf gesetzt wird, ist sicherzustellen, dass der FPolicy Server auch protobuf Deserialisierung unterstützt. Weitere Informationen sind unter "Die Konfiguration der externen FPolicy Engine planen" verfügbar.

Ein FPolicy Ereignis beschreibt, was die FPolicy Richtlinie überwachen soll. Ereignisse bestehen aus den zu überwachenden Protokollen und Dateivorgängen und können eine Liste von Filtern enthalten. Ereignisse verwenden Filter, um die Liste der überwachten Ereignisse einzugrenzen, für die die FPolicy externe Engine Benachrichtigungen senden muss. Ereignisse geben außerdem an, ob die Richtlinie Volumenvorgänge überwacht.

Ab ONTAP 9.14.1 ermöglicht FPolicy die Einrichtung von "persistente Speicher" zum Erfassen von Dateizugriffsereignissen für asynchrone, nicht obligatorische Richtlinien in der SVM. Synchrone (obligatorische oder nicht obligatorische) und asynchron obligatorische Konfigurationen werden nicht unterstützt.

Persistente Speicher können die Client-E/A-Verarbeitung von der FPolicy-Benachrichtigungsverarbeitung entkoppeln, um die Client-Latenz zu reduzieren.

Ab ONTAP 9.15.1 ist die Konfiguration des persistenten Speichers mit FPolicy vereinfacht. Der persistent-store-create Befehl automatisiert die Volume-Erstellung für die SVM und konfiguriert das Volume für den persistenten Store.

Die FPolicy-Richtlinie ist dafür verantwortlich, dem entsprechenden Geltungsbereich die Menge der zu überwachenden Ereignisse zuzuordnen und festzulegen, für welche der überwachten Ereignisse Benachrichtigungen an den festgelegten FPolicy-Server (oder an die native Engine, falls keine FPolicy-Server konfiguriert sind) gesendet werden müssen. Die Richtlinie definiert außerdem, ob der FPolicy-Server privilegierten Zugriff auf die Daten erhält, für die er Benachrichtigungen empfängt. Ein FPolicy-Server benötigt privilegierten Zugriff, wenn der Server auf die Daten zugreifen muss. Typische Anwendungsfälle, in denen privilegierter Zugriff erforderlich ist, sind Dateisperrung, Quotenverwaltung und hierarchische Speicherverwaltung. In der Richtlinie wird festgelegt, ob die Konfiguration für diese Richtlinie einen FPolicy-Server oder den internen „native“ FPolicy-Server verwendet.

Eine Richtlinie legt fest, ob eine Überprüfung obligatorisch ist. Wenn eine Überprüfung obligatorisch ist und alle FPolicy Server ausgefallen sind oder innerhalb eines definierten Zeitüberschreitung keine Antwort von den FPolicy Servern empfangen wird, wird der Dateizugriff verweigert.

Die Grenzen einer Richtlinie sind die SVM. Eine Richtlinie kann nicht auf mehr als eine SVM angewendet werden. Eine bestimmte SVM kann jedoch mehrere FPolicy Richtlinien haben, die jeweils dieselbe oder unterschiedliche Kombination aus Geltungsbereich, Ereignis und externer Serverkonfiguration aufweisen.

Der FPolicy-Bereich legt fest, auf welche Volumes, Freigaben oder Exportrichtlinien die Richtlinie angewendet wird oder von der Überwachung ausgeschlossen wird. Ein Bereich legt außerdem fest, welche Dateierweiterungen in die FPolicy-Überwachung einbezogen oder von dieser ausgeschlossen werden.

Wenn die Richtlinie aktiviert ist, werden die Kontrollkanäle und optional die privilegierten Datenkanäle verbunden. Der FPolicy Prozess auf den Knoten, an denen die SVM beteiligt ist, beginnt mit der Überwachung des Datei- und Ordnerzugriffs und sendet bei Ereignissen, die den konfigurierten Kriterien entsprechen, Benachrichtigungen an die FPolicy Server (oder an die native Engine, falls keine FPolicy Server konfiguriert sind).