ONTAP 9

to Japanese version

Requirements, considerations, and best practices for configuring FPolicy

Before you create and configure FPolicy configurations on your SVMs, you need to be aware of certain requirements, considerations, and best practices for configuring FPolicy.

FPolicy features are configured either through the command line interface (CLI) or through REST APIs.

Requirements for setting up FPolicy

Before you configure and enable FPolicy on your storage virtual machine (SVM), you need to be aware of certain requirements.

  • All nodes in the cluster must be running a version of ONTAP that supports FPolicy.

  • If you are not using the ONTAP native FPolicy engine, you must have external FPolicy servers (FPolicy servers) installed.

  • The FPolicy servers must be installed on a server accessible from the data LIFs of the SVM where FPolicy policies are enabled.

    Beginning with ONTAP 9.8, ONTAP provides a client LIF service for outbound FPolicy connections with the addition of the data-fpolicy-client service. Learn more about LIFs and service policies.
  • The IP address of the FPolicy server must be configured as a primary or secondary server in the FPolicy policy external engine configuration.

  • If the FPolicy servers access data over a privileged data channel, the following additional requirements must be met:

    • SMB must be licensed on the cluster.

      Privileged data access is accomplished using SMB connections.

    • A user credential must be configured for accessing files over the privileged data channel.

    • The FPolicy server must run under the credentials configured in the FPolicy configuration.

    • All data LIFs used to communicate with the FPolicy servers must be configured to have cifs as one of the allowed protocols.

      This includes the LIFs used for passthrough-read connections.

  • Beginning with ONTAP 9.14.1, FPolicy allows you to set up a persistent store to capture file access events for asynchronous non-mandatory policies in the SVM. Persistent stores can help decouple client I/O processing from FPolicy notification processing to reduce client latency. Synchronous (mandatory or non-mandatory) and asynchronous mandatory configurations are not supported.

Best practices and recommendations when setting up FPolicy

When setting up FPolicy on storage virtual machines (SVMs), get familiar with the general configuration best practices and recommendations to ensure that your FPolicy configuration provides robust monitoring performance and results that meet your requirements.

Policy configuration

Configuration of the FPolicy external engine, events, and scope for SVMs can improve your overall experience and security.

  • Configuration of the FPolicy external engine for SVMs:

    • Providing additional security comes with a performance cost. Enabling Secure Sockets Layer (SSL) communication has a performance effect on accessing shares.

    • The FPolicy external engine should be configured with more than one FPolicy server to provide resiliency and high availability of FPolicy server notification processing.

  • Configuration of FPolicy events for SVMs:

    Monitoring file operations influences your overall experience. For example, filtering unwanted file operations on the storage side improves your experience. We recommend setting up the following configuration:

    • Monitoring the minimum types of file operations and enabling the maximum number of filters without breaking the use case.

    • Using filters for getattr, read, write, open, and close operations. The SMB and NFS home directory environments have a high percentage of these operations.

  • Configuration of FPolicy scope for SVMs:

    Restrict the scope of the policies to the relevant storage objects, such as shares, volumes, and exports, instead of enabling them across the entire SVM. We recommend checking the directory extensions. If the is-file-extension-check-on-directories-enabled parameter is set to true, directory objects are subjected to the same extension checks as regular files.

Network configuration

Network connectivity between the FPolicy server and the controller should be of low latency. We recommend separating FPolicy traffic from client traffic by using a private network.

In addition, you should place external FPolicy servers (FPolicy servers) in close proximity to the cluster with high-bandwidth connectivity to provide minimal latency and high-bandwidth connectivity.

For a scenario in which the LIF for FPolicy traffic is configured on a different port to the LIF for client traffic, the FPolicy LIF might fail over to the other node because of a port failure. As a result, the FPolicy server becomes unreachable from the node which causes the FPolicy notifications for file operations on the node to fail. To avoid this issue, verify that the FPolicy server can be reached through at least one LIF on the node to process FPolicy requests for the file operations performed on that node.

Hardware configuration

You can have the FPolicy server on either a physical server or a virtual server. If the FPolicy server is in a virtual environment, you should allocate dedicated resources (CPU, network, and memory) to the virtual server.

The cluster node-to-FPolicy server ratio should be optimized to ensure that FPolicy servers are not overloaded, which can introduce latencies when the SVM responds to client requests. The optimal ratio depends on the partner application for which the FPolicy server is being used.

Multiple-policy configuration

The FPolicy policy for native blocking has the highest priority, irrespective of the sequence number, and decision-altering policies have a higher priority than others. Policy priority depends on the use case.

Size considerations

FPolicy performs in-line monitoring of SMB and NFS operations, sends notifications to the external server, and waits for a response, depending on the mode of external engine communication (synchronous or asynchronous). This process affects the performance of SMB and NFS access and CPU resources.

Performance is affected by several factors including the number of users, workload characteristics, such as operations per user and data size, network latency, and failure or server slowness.

Monitor performance

FPolicy is a notification-based system. Notifications are sent to an external server for processing and to generate a response back to ONTAP. This round-trip process increases latency for client access.

Monitoring the performance counters on the FPolicy server and in ONTAP gives you the capability to identify bottlenecks in the solution and to tune the parameters as necessary for an optimal solution. For example, an increase in FPolicy latency has a cascading effect on SMB and NFS access latency. Therefore, you should monitor both workload (SMB and NFS) and FPolicy latency. In addition, you can use quality-of-service policies in ONTAP to set up a workload for each volume or SVM that is enabled for FPolicy.

We recommend running the statistics show –object workload command to display workload statistics. In addition, you should monitor the following parameters:

  • Average, read, and write latencies

  • Total number of operations

  • Read and write counters

You can monitor the performance of FPolicy subsystems by using the following FPolicy counters.

You must be in diagnostic mode to collect statistics related to FPolicy.
Steps
  1. Collect FPolicy counters:

    1. statistics start -object fpolicy -instance instance_name -sample-id ID

    2. statistics start -object fpolicy_policy -instance instance_name -sample-id ID

  2. Display FPolicy counters:

    1. statistics show -object fpolicy –instance instance_name -sample-id ID

    2. statistics show -object fpolicy_server –instance instance_name -sample-id ID

    The fpolicy and fpolicy_server counters give you information on several performance parameters which are described in the following table.

    Counters Description

    “fpolicy” counters

    aborted_requests

    Number of screen requests for which processing is aborted on the SVM

    event_count

    List of events resulting in notification

    max_request_latency

    Maximum screen requests latency

    outstanding_requests

    Total number of screen requests in process

    processed_requests

    Total number of screen requests that went through fpolicy processing on the SVM

    request_latency_hist

    Histogram of latency for screen requests

    requests_dispatched_rate

    Number of screen requests dispatched per second

    requests_received_rate

    Number of screen requests received per second

    “fpolicy_server” counters

    max_request_latency

    Maximum latency for a screen request

    outstanding_requests

    Total number of screen requests waiting for response

    request_latency

    Average latency for screen request

    request_latency_hist

    Histogram of latency for screen requests

    request_sent_rate

    Number of screen requests sent to FPolicy server per second

    response_received_rate

    Number of screen responses received from FPolicy server per second

Manage FPolicy workflow and dependency on other technologies

We recommend disabling an FPolicy policy before making any configuration changes. For example, if you want to add or modify an IP address in the external engine configured for the enabled policy, first disable the policy.

If you configure FPolicy to monitor FlexCache volumes, We recommend that you not configure FPolicy to monitor read and getattr file operations. Monitoring these operations in ONTAP requires the retrieval of inode-to-path (I2P) data. Because I2P data cannot be retrieved from FlexCache volumes, it must be retrieved from the origin volume. Therefore, monitoring these operations eliminates the performance benefits that FlexCache can provide.

When both FPolicy and an off-box antivirus solution are deployed, the antivirus solution receives notifications first. FPolicy processing starts only after antivirus scanning is complete. It is important that you size antivirus solutions correctly because a slow antivirus scanner can affect overall performance.

Passthrough-read upgrade and revert considerations

There are certain upgrade and revert considerations that you must know about before upgrading to an ONTAP release that supports passthrough-read or before reverting to a release that does not support passthrough-read.

Upgrading

After all nodes are upgraded to a version of ONTAP that supports FPolicy passthrough-read, the cluster is capable of using the passthrough-read functionality; however, passthrough-read is disabled by default on existing FPolicy configurations. To use passthrough-read on existing FPolicy configurations, you must disable the FPolicy policy and modify the configuration, and then reenable the configuration.

Reverting

Before reverting to a version of ONTAP that does not support FPolicy passthrough-read, you must meet the following conditions:

  • Disable all the policies using passthrough-read, and then modify the affected configurations so that they do not use passthrough-read.

  • Disable FPolicy functionality on the cluster by disabling every FPolicy policy on the cluster.

Before reverting to a version of ONTAP that does not support persistent stores, ensure that none of the Fpolicy policies have a configured persistent store. If a persistent store is configured, the revert will fail.

Top of Page