Additional contributions by Rishi Bharadwaj, Praveen Padia, Gurunath Gudi, Bibhash Seth, Hardik Chandrahas, Droan Malik and Anoop Menon.

Introduction

In the hybrid multicloud world, applications need more agility to run anywhere and to efficiently move their application data and storage configuration. Nutanix is committed to continuously innovate to support this journey. A new feature called “Storage Policy” introduces storage configuration at a per VM level.

On Nutanix storage, configuration features such as data redundancy, encryption (for security), data compression, deduplication, and erasure coding (storage space optimization) are defined at a container level. A container is a logical segmentation of the physical storage space and contains a group of VMs or files (vDisks). However, managing containers across clusters in a hybrid cloud environment introduces a lot of complexity. Storage Policies simplifies this experience by bringing the storage configuration closer to the application where users have the ability to configure attributes at a per VM (VM group) level across clusters.

Policy-based multi-cluster storage configuration enables workload/application mobility across clusters without worrying about underlying storage container configuration. Customers can set and manage storage policy templates by departments, applications, and business Criticality (for example, policies for database VMs) from Prism Central.

Problem Statement

All VMs or files (vDisks) inherit the storage properties of the container they reside in, which leads to certain problems at scale:

• Little to No Flexibility – Users have to make all decisions upfront while configuring containers. Changes required for one VM impact all other VMs residing in the container. Users can create new containers and migrate the VMs from one container to the other, using the container migration feature offered by Nutanix for AHV. However, this has downsides like extra copies of data during migration, VM stun times, and scale limitations. Also, a large number of containers can become a hindrance in manageability.
• Boundary – A container’s boundary is limited to the cluster it is created in. In large scale environments with multiple clusters that manage multiple clusters (Prism Element), VMs that require similar configuration on different clusters require containers with similar configuration on every such cluster. This again increases the operational overhead.

Solution

With Storage Policies, a customer or user has the ability to define storage attributes at the VM level and improve the manageability at scale.

• Flexibility – Easily move entities between different storage policies without migrating data, which helps avoid creation of extra copies or impacts to VM performance.
• Boundary – Use Prism Central to configure storage policies. The boundary is defined by the Prism Central and the Prism Element instances managed by Prism Central. Storage policies help reduce management redundancy by allowing users to create one policy that can manage VMs with similar storage requirements across different clusters. 
• Monitoring and Reporting – Increase transparency by tracking the final state of VM data.  For example, a user can now determine whether the underlying file system has encrypted all the data for a VM.

The storage attributes supported within a policy are as follows:

• Replication Factor (RF) – Data redundancy/availability. A storage policy can dictate whether there should be two or three copies of VM data.
• Encryption – Data security. A storage policy can dictate whether VM data at rest should be encrypted.
• Compression – Data reduction aimed at space optimization. A storage policy can dictate whether VM data should be compressed and supports both inline and post-process compression.
• IOPS throttling – VM performance. A storage policy can dictate the maximum number of I/O operations allowed per second for a VM.

Although configuring storage properties on a container became a legacy use case with the advent of storage policies, containers are still supported for two primary reasons: all storage properties are not available within policies, necessitating the use of containers, and existing users may want to use storage policies in setups where containers are already present (brownfield systems). As a precedence rule, policy settings always outweigh container settings. For example, if a container is set to RF3 and the policy is set to RF2, the storage subsystem creates only two copies of VM data.

Setting Up Storage Policies

Users must configure storage policies from a Prism Central VM. They can create storage policies with their desired configuration, and policies are applied based on categories associated with the VMs.

Users can modify existing storage policies as well by changing properties or associated categories. They are also allowed to delete existing storage policies. The system chooses an appropriate storage policy to apply on the affected VMs.

Monitoring and Compliance Reporting

With Storage Policies, policy configuration and subsequent application provide more transparency regarding the status of the data transformation. Users can now monitor whether the policy has been fully realized on the VM. The system reports compliance of an entity (VM) with respect to the applied policy, indicating the progress status. There are three states possible:

• IN-PROGRESS – The system is in the process of carrying out the requisite operations to be able to realize the policy.
• COMPLIANT – The system has completed all operations and the data adheres to the configuration specified. For example, data is completely encrypted when policy requires encryption of the VMs it is managing.
• NON-COMPLIANT – The system cannot realize the policy configuration unless the user intervenes. For example, an encryption license is not enabled, but the policy requires encryption, or RF3 is configured on a policy, but the VM resides on a four-node cluster. Users can add more nodes to a cluster to move the VM to a COMPLIANT state.

A VM can be in any one of the above-mentioned states at a point in time and can transition from one state to the other based on events within the system.

Reporting also covers VMs on which policies could not be applied. Such VMs are termed as Non-Realized VMs and can occur for hypervisor incompatibility (the feature is supported only on AHV), AOS version incompatibility, or when multiple policies act on a VM due to categories attached to the VM.

For more detailed information, see Storage Policies Summary View.