Skip to content

Latest commit

 

History

History
114 lines (75 loc) · 5.43 KB

concept_write_speed.adoc

File metadata and controls

114 lines (75 loc) · 5.43 KB
sidebar permalink keywords summary
sidebar
concept_write_speed.html
write speed, high write speed, normal write speed, nvfail, writing speed, ldm, low durability mode
Cloud Manager enables you to choose normal or high write speed for Cloud Volumes ONTAP. 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.

Write speed

Cloud Manager enables you to choose normal or high write speed for Cloud Volumes ONTAP. 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.

High write speed is supported with all types of single node systems. It’s also supported with HA pairs in AWS and Azure when using a specific instance or VM type (refer to the sections below for the list of supported instances and VM types). High write speed is not supported with HA pairs in GCP.

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.

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.

If you use an HA pair, Cloud Volumes ONTAP supports high write speed with the following instance types, starting with the 9.8 release:

  • c5.9xlarge

  • c5.18xlarge

  • c5d.4xlarge

  • c5d.9xlarge

  • c5d.18xlarge

  • c5n.9xlarge

  • c5n.18xlarge

  • m5.2xlarge

  • m5.4xlarge

  • m5.16xlarge

  • m5d.8xlarge

  • m5d.12xlarge

  • m5n.2xlarge

  • r5.2xlarge

  • r5.8xlarge

  • r5.12xlarge

  • r5d.2xlarge

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 the following VM types, starting with the 9.8 release:

  • DS5_v2

  • DS14_v2

  • DS15_v2

  • E48s_v3

Google Cloud

If you use a single node system, Cloud Volumes ONTAP supports high write speed with all machine types.

Cloud Volumes ONTAP doesn’t support high write speed with HA pairs in Google Cloud.

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 you choose high write speed and data loss occurs, the system should be able to boot up and continue to serve data without user intervention. Two EMS messages will be reported when a node runs into data loss. One is wafl.root.content.changed with the ERROR severity level event, the other is nv.check.failed with the DEBUG severity level event. Both messages must be present as an indication of data loss.

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