This page provides an overview of the FlexCache feature.
About FlexCache
NetApp FlexCache accelerates data access, reduces WAN latency, and lowers WAN bandwidth costs for read-intensive workloads, especially when clients repeatedly access the same data. When you create a FlexCache volume, it acts as a remote cache of an existing (origin) volume. This cache stores only frequently accessed hot data of the origin volume.
When a FlexCache volume receives a read request for hot data it contains, it responds faster than the origin volume because the data has a shorter distance to travel to the client. If a FlexCache volume receives a read request for infrequently accessed cold data, it retrieves the required data from the origin volume, stores it, and then serves the client request. Subsequent read requests for that data are then served directly from the FlexCache volume. After the first request, the data no longer needs to travel across the network, or be served from a heavily loaded system.
While applications can write to a FlexCache volume, these writes are sent to the origin volume to maintain cache coherence.
The integration of FlexCache with Google Cloud NetApp Volumes lets you provision cache volumes within your Google network to improve performance for hybrid cloud environments. This feature supports the transition of workloads to the hybrid cloud by caching data from an on-premises data center to the cloud.
Volumes in NetApp Volumes can't serve as origin volumes.
FlexCache has the following capabilities:
Write behavior
When data is written to a FlexCache volume, the write operation is passed to the origin volume. The cache acknowledges the write once the origin confirms it. Writing to a file invalidates its cached copy, and the cache retrieves it again upon the next access.
Cache invalidation due to access time updates
ONTAP provides a volume-level field called -atime-update to manage access time
updates on files and directories that are read using READ, READLINK, and
READDIR.
Access time updates on either origin or cache volumes can trigger file
invalidations that reduce cache effectiveness and cause slow performance and
high latency for file access. To prevent this, disable access time updates on
the origin volume using the ONTAP volume modify -atime-update
command.
FlexCache volumes in NetApp Volumes inherit the -atime-update
setting from the origin, which can increase cache invalidations. Therefore, we
recommend that you disable access time updates on the origin volume.
Global file locking
Global file locking, disabled by default, prevents reads across all related cached files. When enabled, modifications to the origin volume are suspended until all FlexCache volumes are online. This feature should only be enabled if you have control over the reliability of the connections between the cache and origin, as modifications can be suspended or timeouts if FlexCache volumes are offline.
CIFS change notifications
The SMB protocol provides a mechanism to notify SMB clients of changes made to a volume by other clients. This allows applications, such as Windows File Explorer, to update their views without polling the volume. This optional feature is useful for caches where interactive users access files on SMB volumes through Windows Explorer. Otherwise, it should be disabled to reduce notification load.
Cache prepopulation
While NetApp Volumes doesn't offer API support for prepopulating the cache, you can pre-warm it from the client side. This process involves reading the files to ensure their data is loaded into the cache.
The following tabs show the commands to pre-warm the cache for different client operating systems. These commands also typically pre-warm the directory listings.
Linux or UNIX clients
To pre-warm the cache:
find DIR_PATH -type f -print -exec sh -c 'cat "$1" > /dev/null' sh {} \;
Windows clients
To pre-warm the cache:
for /f "delims=" %i in ('dir /b /s /a-d DIR_PATH') do @type "%i" >NUL
To accelerate the prepopulation process, consider using a data migration tool like XCP.
To read the data and populate the cache using XCP:
xcp -md5 -q SERVER:/PATH