ONTAP Select is NetApp’s solution for software defined storage. Since its inception, the main characteristic of ONTAP Select has been flexibility. It is reflected in the various hardware architectures that one can run ONTAP Select on. This flexibility is a direct consequence of having designed ONTAP Select to install on top of a hypervisor. In general, as long as a hardware layer is supported by our choice of hypervisors, you can install and run ONTAP Select on it. Please consult our interoperability matrix (IMT) for a list of supported hypervisors and versions. Today I want to focus on a specific architecture, one that we call Virtual NAS or vNAS.
vNAS is an umbrella term used to define any ONTAP Select hardware architecture that does not use direct attached storage (DAS). I am always amazed at the wide gamut of hardware configurations that our customers use to install ONTAP Select. We have customers who install on top of HCI stacks in order to bring NAS services to those platforms. Other customers install on top of legacy arrays in order to provide truly scalable multi tenancy services above and beyond what the underlying array can support natively. Finally, we have customers that use JBOD units in order to add data management services to commodity hardware. What ties all these use cases together is the ability to replicate and protect data via a common set of ONTAP APIs and commands using SnapMirror and SnapVault protocols.
ONTAP Select 9.4 adds support for ONTAP HA for vNAS configurations. In prior releases, we relied on hypervisor provided, VM level HA, for a measure of high availability. While that ensured that server level hardware errors would not lead to data unavailability, it did not prevent managed outages during ONTAP code upgrades. Customers used to FAS and AFF non-disruptive operations and non-disruptive upgrades (NDO/NDU) were looking for that same level of functionality in ONTAP Select.
Before we go any further, a little background on ONTAP Select High Availability architecture and how it is different than ONTAP on FAS/AFF hardware. ONTAP Select provides an HA architecture on top of a commodity server the only way possible: by making a full copy of the data, someplace else. In this case, the data is synchronously mirrored and stored on the other node. In other words, if a commodity server which may have multiple single points of failure becomes unavailable for whatever reason, ONTAP Select will automatically start serving that unavailable node’s data, using the mirrored copy of data available on the surviving node. The fact that the nodes were synchronously mirrored means that the solution RPO is 0 and the RTO is under 60 seconds, which is the maximum guaranteed time of a failover when using ONTAP Select.
In the case of ONTAP Select HA for vNAS, the active copy of the data (hosted by one VM node) ends up side by side, in the same array, with the mirror copy of the data (hosted by the other VM node). That means that as a best practice, the array hosting both ONTAP Select VMs should have its deduplication policies turned on.
HCI solutions do not usually support modifications of their VM level protection schema. Older arrays and JBODS however, usually do allow for the creation of RAID 0 LUNs. In those cases, I would recommend creating separate datastores for each ONTAP Select VM, each of which would be backed by a RAID 0 LUN.
It is also important to note that ONTAP Select supports FabricPool for all configurations, including vNAS. With up to 20:1 data reduction on the primary tier, FabricPool is significantly better at reducing storage utilization rates than array side storage efficiency policies. For more information on FabricPool, check out the following: https://www.netapp.com/us/media/tr-4695.pdf
Want to get started with ONTAP Select? Download the free 90-day trial version of ONTAP Select today!