Write speed
BlueXP enables you to choose normal or high write speed for most Cloud Volumes ONTAP configurations. Before you choose a write speed, you should understand the differences between the normal and high settings and risks and recommendations when using high write speed.
Normal write speed
When you choose normal write speed, data is written directly to disk. When data is written directly to disk, reduces the likelihood of data loss in the event of an unplanned system outage, or a cascading failure involving an unplanned system outage (HA pairs only).
Normal write speed is the default option.
High write speed
When you choose high write speed, data is buffered in memory before it is written to disk, which provides faster write performance. Due to this caching, there is the potential for data loss if an unplanned system outage occurs.
The amount of data that can be lost in the event of an unplanned system outage is the span of the last two consistency points. A consistency point is the act of writing buffered data to disk. A consistency point occurs when the write log is full or after 10 seconds (whichever comes first). However, the performance of the storage provided by your cloud provider can affect consistency point processing time.
When to use high write speed
High write speed is a good choice if fast write performance is required for your workload and you can withstand the risk of data loss in the event of an unplanned system outage, or a cascading failure involving an unplanned system outage (HA pairs only).
Recommendations when using high write speed
If you enable high write speed, you should ensure write protection at the application layer, or that the applications can tolerate data loss, if it occurs.
High write speed with an HA pair in AWS
If you plan to enable high write speed on an HA pair in AWS, you should understand the difference in protection levels between a multiple Availability Zone (AZ) deployment and a single AZ deployment. Deploying an HA pair across multiple AZs provides more resiliency and can help to mitigate the chance of data loss.
Configurations that support high write speed
Not all Cloud Volumes ONTAP configurations support high write speed. Those configurations use normal write speed by default.
AWS
If you use a single node system, Cloud Volumes ONTAP supports high write speed with all instance types.
Starting with the 9.8 release, Cloud Volumes ONTAP supports high write speed with HA pairs when using almost all supported EC2 instance types, except for m5.xlarge and r5.xlarge.
Azure
If you use a single node system, Cloud Volumes ONTAP supports high write speed with all VM types.
If you use an HA pair, Cloud Volumes ONTAP supports high write speed with several VM types, starting with the 9.8 release. Go to the Cloud Volumes ONTAP Release Notes to view the VM types that support high write speed.
Google Cloud
If you use a single node system, Cloud Volumes ONTAP supports high write speed with all machine types.
If you use an HA pair, Cloud Volumes ONTAP supports high write speed with several VM types, starting with the 9.13.0 release. Go to the Cloud Volumes ONTAP Release Notes to view the VM types that support high write speed.
How to select a write speed
You can choose a write speed when you create a new working environment and you can change the write speed for an existing system.
What to expect if data loss occurs
If data loss occurs due to high write speed, the Event Management System (EMS) reports the following two events:
-
Cloud Volumes ONTAP 9.12.1 or later
NOTICE nv.data.loss.possible: An unexpected shutdown occurred while in high write speed mode, which possibly caused a loss of data.
-
Cloud Volumes ONTAP 9.11.0 to 9.11.1
DEBUG nv.check.failed: NVRAM check failed with error "NVRAM disabled due to dirty shutdown with High Write Speed mode"
ERROR wafl.root.content.changed: Contents of the root volume '' might have changed. Verify that all recent configuration changes are still in effect..
-
Cloud Volumes ONTAP 9.8 to 9.10.1
DEBUG nv.check.failed: NVRAM check failed with error "NVRAM disabled due to dirty shutdown"
ERROR wafl.root.content.changed: Contents of the root volume '' might have changed. Verify that all recent configuration changes are still in effect.
When this happens, Cloud Volumes ONTAP should be able to boot up and continue to serve data without user intervention.
How to stop data access if data loss occurs
If you are concerned about data loss, want the applications to stop running upon data loss, and the data access to be resumed after the data loss issue is properly addressed, you can use the NVFAIL option from the CLI to achieve that goal.
- To enable the NVFAIL option
-
vol modify -volume <vol-name> -nvfail on
- To check NVFAIL settings
-
vol show -volume <vol-name> -fields nvfail
- To disable the NVFAIL option
-
vol modify -volume <vol-name> -nvfail off
When data loss occurs, an NFS or iSCSI volume with NVFAIL enabled should stop serving data (there's no impact to CIFS which is a stateless protocol). For more details, refer to How NVFAIL impacts access to NFS volumes or LUNs.
- To check the NVFAIL state
-
vol show -fields in-nvfailed-state
After the data loss issue is properly addressed, you can clear the NVFAIL state and the volume will be available for data access.
- To clear the NVFAIL state
-
vol modify -volume <vol-name> -in-nvfailed-state false