FPolicy: What is it and what does it do?

Native File Blocking/File Blocking:

Native FPolicy configurations use the Data ONTAP internal FPolicy engine to monitor and block file operations based on the file's extension. This solution does not require external FPolicy servers (FPolicy servers). Using a native file blocking configuration is appropriate when this simple solution is all that is needed.

File blocking allows for a more robust method to monitor and block file operation based on the files magic number signature. This is similar to how anti-virus scanner detect viruses.

For more information, see the following KBs:

• FPolicy: Native File Blocking
• FPolicy: File Blocking

Auditing:

FPolicy Auditing is a software-based solution for data-usage management. With it organizations can see, understand, and manage who is using data to control data access and enforce compliance with data-usage policies. Auditing assists in addressing the growing need for regulating data usage within organizations, enabling full visibility and accountability of data usage for legal, financial, data-security, intellectual-property, and data-privacy purposes.

For more information, see the following KB: FAQ: FPolicy: Auditing

Quotas:

Quotas lets organizations manage their user-generated data proactively to help increase efficiency and reduce risk. This is done by consistently monitoring data creation activities to identify changing trends and needs, using hard or soft quotas to monitor growth in file shares and trigger actions when predetermined sizes are reached, allowing responsibility for data to be placed firmly in the hands of those who create and use it.

Hierarchical Storage Management (HSM):

HSM addresses storage costs and resource issues by providing an automated and integrated solution for archiving file server content. This solution can lower storage costs and manage file lifecycles. The replacement of the migrated files with reference files results in a significant reduction of storage space on the primary storage. When there is a user or application access to a reference file, the dg file migration adapter automatically initiates a recall operation, and the reference file is replaced with the original file.

File Replication:

File Replication allow for real-time synchronization across all participating servers, regardless of where changes occur. The file-locking component prevents users from accessing files that users at another location currently work on. The entire system works cross platform between Windows and NetApp clustered Data ONTAP and Data ONTAP operating in 7-Mode. One or more File Collaboration jobs can be created across the environment to work with different groupings of projects, data, servers, and/or sites. Each job consists of two or more participating servers and a folder structure on each participating file server or NetApp system.

Basic Communication Overview:

Depending on the feature use, excluding file blocking, one or more of the following protocols will be used to communicate with the FPolicy server, http(s), tcp, or CIFS(NFSv4 possible in the future). Every node that participates on each Storage Virtual Machine (SVM) initiates a connection to an external FPolicy server (FPolicy server) using TCP/IP. Connections to the FPolicy servers are set up using node data LIFs; therefore, a participating node can set up a connection only if the node has an operational data LIF for the SVM.

Each FPolicy process on participating nodes attempts to establish a connection with the FPolicy server when the policy is enabled. It uses the IP address and port of the FPolicy external engine specified in the policy configuration.
The connection establishes a control channel from each of the nodes participating on each SVM to the FPolicy server through the data LIF. In addition, if IPv4 and IPv6 data LIF addresses are present on the same participating node, FPolicy attempts to establish connections for both IPv4 and IPv6. Therefore, in a scenario where the SVM extends over multiple nodes or if both IPv4 and IPv6 addresses are present, the FPolicy server must be ready for multiple control channel setup requests from the cluster after the FPolicy policy is enabled on the SVM.

For example, if a cluster has three nodes—Node1, Node2, and Node3—and SVM data LIFs are spread across only Node2 and Node3, control channels are initiated only from Node2 and Node3, irrespective of the distribution of data volumes. Say that Node2 has two data LIFs—LIF1 and LIF2—that belong to the SVM and that the initial connection is from LIF1. If LIF1 fails, FPolicy attempts to establish a control channel from LIF2.

Synchronous vs Asynchronous communication:

Policies can be synchronous or asynchronous. Policy being sync/async is collected from FPolicy configuration.

Synchronous-mode policy - A policy is synchronous if Data ONTAP notifies the FPolicy server and waits for its response to either allow or deny the request. This mode of policy is used if the process path of any file operation request needs to be altered. For example, 'Quota on directory' application would need the policy to be synchronous, because, once the quota is exceeded, the file operations trying to write more data to the directories concerned need to be denied.

Asynchronous-mode policy - Sometimes, also referred to as notify-only policy. After sending the notification in-lieu of a file operation, Data ONTAP continues the processing of the file operation. The FPolicy server does not have a way to alter the outcome of the file operation. For example, in file access monitoring application, the FPolicy server is notified of the file operation but the outcome of file operation is not altered. Notification is sent to FPolicy server using XML over TCP. For a given Vserver, there might be multiple policies with different priority.