Storage Containers Test

Each Nutanix container can be configured with a replication factor (RF) of two or three. RF=2 ensures that two copies of data are maintained at all times, allowing the cluster to survive the failure of one node or disk. Similarly, when RF is set to 3 (RF=3), three copies of the data are maintained in the cluster, providing resilience from two simultaneous failures. This level of flexibility allows administrators to dynamically configure data redundancy based on application SLAs and the criticality of the data set.

The value of this measure can be 2 or 3 depending upon the RF setting of the container.

The OpLog acts as a staging area to absorb incoming writes onto a low-latency SSD tier. Upon being written to the local OpLog, the data is synchronously replicated to another one or two Nutanix CVM’s OpLog, depending upon the replication factor (RF) setting of Oplog, before being acknowledged (Ack) as a successful write to the host. For instance, if the RF setting of Oplog is 2, then data will be synchronously replicated to one other Oplog. If RF is 2, then data will be replicated to two other Oplogs.

This ensures that the data exists in at least two or three independent locations and is fault tolerant. NOTE: For RF=3, a minimum of 5 nodes is required since metadata will be RF5.

The value of this measure can be 2 or 3, depending upon the RF setting for Oplog.

The Nutanix Capacity Optimization Engine (COE) is responsible for performing data transformations to increase data efficiency on disk. Currently compression is one of the key features of the COE to perform data optimization. DSF provides both inline and offline flavors of compression to best suit the customer’s needs and type of data.

Inline compression will compress sequential streams of data or large I/O sizes (>64K) in memory before it is written to the Extent Store (SSD + HDD). This includes data draining from OpLog as well as sequential data skipping it.

Offline compression will initially write the data as normal (in an un-compressed state) and then leverage the Curator framework to compress the data cluster wide. When inline compression is enabled but the I/Os are random in nature, the data will be written un-compressed in the OpLog, coalesced, and then compressed in memory before being written to the Extent Store.

The Google Snappy compression library is leveraged which provides good compression ratios with minimal computational overhead and extremely fast compression / decompression rates.

This measure reports the value On if compression is enabled for this container, and the value Off if compression is disabled. The numeric values that correspond to these measure values are listed below:

Note:

By default, this measure reports the values listed in the Measure Value column to indicate whether/not compression is enabled for a container. In the graph of the measure however, the same will be represented using the numeric equivalents only.

Deduplication is the process of eliminating duplicate data, so as to increase the effective capacity in the disk tier, and the system’s RAM and flash tiers.

Nutanix delivers two types of data deduplication to accelerate application performance and to optimize storage capacity. These are namely, Performance tier deduplication and Capacity tier / MapReduce / On-disk deduplication. On-disk deduplication, if enabled for a container, reduces repetitive data in the capacity tier to increase the effective storage capacity of a cluster. This type of deduplication is global and distributed across all nodes in the cluster, minimizing any performance overhead. MapReduce deduplication is particularly useful for virtual desktops with full clones.Performance-trier deduplication can be used without Capacity-tier deduplication but not the other way around.

This measure reports the value On if deduplication is enabled for this container, and the value Off if deduplication is disabled. The numeric values that correspond to these measure values are listed below:

Note:

By default, this measure reports the values listed in the Measure Value column to indicate whether/not on-disk deduplication is enabled for a container. In the graph of the measure however, the same will be represented using the numeric equivalents only.

The Nutanix platform leverages a replication factor (RF) for data protection and availability. This method provides the highest degree of availability because it does not require reading from more than one storage location or data re-computation on failure. However, this does come at the cost of storage resources as full copies are required.

To provide a balance between availability while reducing the amount of storage required, DSF provides the ability to encode data using erasure codes (EC).

Similar to the concept of RAID (levels 4, 5, 6, etc.) where parity is calculated, EC encodes a strip of data blocks on different nodes and calculates parity. In the event of a host and/or disk failure, the parity can be leveraged to calculate any missing data blocks (decoding). In the case of DSF, the data block is an extent group and each data block must be on a different node and belong to a different vDisk.

The number of data and parity blocks in a strip is configurable based upon the desired failures to tolerate. The configuration is commonly referred to as the number of <data blocks>/<number of parity blocks>.

For example, “RF2 like” availability (e.g., N+1) could consist of 3 or 4 data blocks and 1 parity block in a strip (e.g., 3/1 or 4/1). “RF3 like” availability (e.g. N+2) could consist of 3 or 4 data blocks and 2 parity blocks in a strip (e.g. 3/2 or 4/2).

This measure reports the value On if erasure coding is enabled for this container, and the value Off if it is disabled. The numeric values that correspond to these measure values are listed below:

By default, this measure reports the values listed in the Measure Value column to indicate whether/not erasure coding is enabled for a container. In the graph of the measure however, the same will be represented using the numeric equivalents only.

The values that this measure can report and their corresponding numeric values are listed in the table below:

Note:

By default, this measure reports the values listed in the Measure Value column to indicate whether/not the container is marked for removal. In the graph of the measure however, the same will be represented using the numeric equivalents only.

Use the detailed diagnosis of this measure to know which VMs are attached to this container.

Ideally, the value of this measure should be very low. A high value or a steady increase in this value could indicate an I/O processing bottleneck on the container. In such a case, compare the value of the Read IO latency and Write IO latency measures to figure out where the slowness is worst - when processing read requests? or write requests?

If the Total I/O latency measure reports an abnormally high value, then compare the value of these measures to figure out where the slowness is maximum - when processing read requests? or write requests?

A high value for this measure denotes that the container is processing bandwidth-intensive I/O. In such situations, you may want to compare the value of the Read IO bandwidth and Write IO bandwidth measures to know what type of I/O requests are truly contributing to the excessive bandwidth consumptions - read requests? or write requests?

If the value of the Total IO bandwidth measure is high, then you may want to compare the value of the Read IO bandwidth and Write IO bandwidth measures to know what type of I/O requests are truly contributing to the excessive bandwidth consumption - read requests? or write requests?

This measure is a good indicator of the level of I/O activity on the container. A steady and significant increase in the value of this measure could indicate a potential I/O overload. In such situations, you may want to compare the value of the Read IOPS and Write IOPS measures of the container to know what type of IO operations are contributing to the overload.

If the value of the Total IOPS measure is unusually high, then compare the value of these measures for that container to know what is contributing to the unusual I/O activity levels - read requests? or write requests?

The maximum capacity value reflects total available storage regardless of how many containers are defined. Therefore, when you have two containers, it can appear you have twice as much capacity because the field values for both containers show the full amount. This will normally match the storage pool size.

Ideally, the value of this measure should be low.

Ideally, the value of this measure should be high.

A value close to 100% is a cause for concern, as it indicates that the container is rapidly running out of free space. You may want to consider allocating more space to the container to avoid loss of data.

A value less than 50% could be a cause for concern, as it indicates that the storage space in the container is being over-utilized. You may want to consider allocating more space to the container to avoid loss of data.

If storage space is reserved for a container, then that container is guaranteed the availability of the reserved capacity. For instance, if the maximum usable capacity of a container is 40TB, but 10TB is its reserved capacity, then this 10TB of space will be available for the use of the container at any given point in time. Since containers are thin-provisioned and space is consumed on a first come first serve basis, there is no guarantee that storage will be available to this container once the reserved capacity of 10TB is consumed.