Cache Writeback and Scheduled Write-Through Features
This page gives more details about two cache policy features: Writeback Delay, and Scheduled Write-Through.
These options can be configured for cache policies that include write caching. The Core Filer > Manage Cache Policies page shows where to configure these options in the Avere Control Panel.
Determining the Maximum Writeback Delay Value
The writeback delay value is used in read/write cache policies to specify how long a file or directory change can remain in the cache before it is written to the core filer.
Avere OS allows you to set a writeback delay value between 0 seconds and one year. This setting is part of a cache policy, which is configured in the Core Filer > Manage Cache Policies settings page.
When determining the value to set for the maximum writeback delay, consider the following:
The usage period of the average client.
For example, if a standard client is a desk workstation that is used for eight hours per day, you might consider eight hours as a reasonable amount of time.
The importance of the data being worked on by clients.
For example, if clients are being used to input mission-critical data, you might consider 30 minutes, one hour, or two hours as the maximum writeback delay. However, if clients are generating scratch data, which will be changed and discarded frequently, a maximum writeback delay of one day or two weeks might be reasonable.
The amount of data being generated by the client as compared to the capacity of the core filer.
For example, if your core filer is notably slow but your clients are generating data rapidly, you might consider increasing the maximum writeback delay to ensure that the core filer is able to accept data at a steady rate that does not overload it. In this example, a maximum writeback delay value of one minute is far too low for realistic performance gains.
Whether or not you need to change the Local Directories setting for this core filer.
Enabling or disabling local directories on a core filer can take a large amount of time (30 minutes or more). Because the time required is partly dependent on how much data is in the cache, reducing the writeback delay can reduce the time required to turn Local Directories on or off by reducing the amount of data in the cache. Also, if you need to change the Local Directories setting, you can reduce the writeback delay temporarily and wait for the data to be written to the core filer before enabling or disabling Local Directories.
The size of the working set.
A larger working set typically requires a longer maximum writeback delay value for optimal performance.
The schedule on which your core filer performs backup operations.
For example, if your core filer performs a full backup every 24 hours, the maximum writeback delay needs to be less than 24 hours to ensure that each day’s current or new data is backed up. (Scheduled write-through, described below, is another approach to ensuring that data is backed up.)
Consult with your Avere Systems representative to estimate a good initial value for the maximum writeback delay. As you become more familiar with the Avere system and the workload patterns generated by your clients and application servers, you can adjust the maximum writeback delay until you find the optimal value for your environment.
Synchronizing Cached Data with Scheduled Write-Through/Read Mode Periods
This section gives details about the Scheduled Write-Through feature, which can be configured as part of a cache policy. Read Write-Through Scheduling to learn how to set up a schedule on the Core Filer > Manage Cache Policies settings page. (Write-through is configured in the advanced section.)
The scheduled write-through feature cannot be used on cloud core filers.
Most core filers use backup services such as snapshots, mirrors, and Network Data Management Protocol (NDMP) sessions to a tape or disk library, typically in combinations to guarantee data retention in the event of data loss on the core filer. If your cluster is using read/write mode to cache data used by clients, you can schedule “write-through” sessions for the cache to ensure that the modifications are synchronized to the core filer before a scheduled core filer backup.
At the scheduled time, the Avere cluster stops caching write operations (it changes to read mode caching only) and copies all cached changes to the core filer. New write operations are passed through immediately to the core filer. This feature can be referred to as scheduling “read-mode” or “write-through” periods, which are two different names for the same behavior.
The length of the read-mode period can be a specified length of time (for example, five minutes) or can be controlled by a simple external URL polling mechanism. Read Appendix C: Implementing a URL Polling Agent to learn more about creating a polling script.
When read-mode periods are scheduled, the cluster performs the following actions:
Approximately every ten seconds, an internal cluster process compares the current time to the next scheduled read-mode period (also called the target time).
If a read-only period is approaching, the cluster automatically and gradually lowers the value of the maximum writeback delay for read-write mode, causing the cluster to write changed data from clients back to the core filer more aggressively.
The cluster continues to lower the value as necessary as the target time gets closer. As a result, the cluster has written all changed data to the core filer when the scheduled read-only period starts.
When the read-only period starts, the cluster automatically switches all client access to read-only (write-through) mode. Any changes made by clients during this period are written directly to the core filer, with the Avere cluster retaining information about changed data and metadata. The Avere cluster continues to cache client read requests.
The cluster remains in read-only mode until one of the following events occurs:
- The polling URL returns the string
RELEASE Core Filer SYNCto the Avere cluster - The specified waiting period expires
Choose one of these when you configure the schedule in the Cache Policy. You also must specify the URL to poll or amount of time to wait.
- The polling URL returns the string
When the read-only period ends, the cluster switches back to read/write mode at the originally specified maximum writeback delay. It stays in that mode until the next scheduled read-only period approaches.