NetApp FAS Series Reviews

Virtual Volumes is the flagship feature of vSphere 6.0 as they enable VM granular storage management and NetApp FAS running Clustered Data ONTAP 8.3 is one of the first platforms to support the technology.

Today storage administrators have to explain to the VM administrators how to identify which datastores to use for each class of VM, which is typically achieved using a combination of documentation and datastore naming conventions – however, consistency and compliance are difficult to achieve.

Virtual Volumes changes this by enabling the storage administrator to provide vCenter with detailed information on the capabilities of each datastore. VM Storage Policies, whilst they existed in previous versions of vSphere were not sophisticated enough to query the actual storage for its capabilities, the VMware APIs for Storage Awareness (VASA) Provider 2.0 resolves this problem. Now the VM administrator can create VMs using Virtual Volumes and use the VM Storage Policy wizard to easily determine which datastores are compatible with its needs.

What components are required for Virtual Volumes?

VASA Provider (VP)The NetApp VP is deployed as an OVA virtual appliance and is managed by the Virtual Storage Console plugged in to the vSphere Web Client. VMs running on Virtual Volumes require that the VP is running in order to create the swap Virtual Volume at power on – the VP should not be running on Virtual Volumes since it would be dependent on itself.

Storage Container (SC)A SC is a set of FlexVol volumes used for Virtual Volume datastores. All the FlexVols within a SC must be accessed using the same protocol (NFS, iSCSI, or FC) and be owned by the same Storage Virtual Machine (SVM), but they can be hosted on different aggregates and nodes of the NetApp cluster.

Protocol Endpoint (PE)The IO path to a Virtual Volume is through a PE with the Virtual Volume bound to the PE through a binding call managed by the VP. The VP determines which PE is on the same node as the FlexVol containing the Virtual Volume and binds the Virtual Volume to that PE.

For block protocols, a PE is a small (4MB) LUN, and the VP creates one PE in each FlexVol that is part of a Virtual Volume datastore. The PE is automatically mapped to initiator groups created and managed by the VP.

For NFS, a PE is a mount point to the root of the SVM and is created by the VP for each data LIF of the SVM using the LIF’s IP address. The PE is automatically created when the first Virtual Volume datastore is created on the SVM along with the appropriate export policy rules.

Storage Capability Profile (SCP)A SCP is a set of capabilities for a volume or set of volumes and may include features such as availability, performance, capacity, space efficiency, replication or protocol.

How could things be improved in the future?

Today De-duplication, Compression, SnapMirror and SnapVault policies are applied to FlexVols – it would be useful if they could also be specified for an individual Virtual Volume, which in turn would enable MetroCluster to non-disruptively “move” an active Virtual Volume from one site to another.

It is great to see that NetApp is ahead of the game with regard to support for Virtual Volumes – it is also nice to see that the 8.3 release can be installed on older versions of hardware allowing FAS customers, who purchased their systems a number of years ago, to take advantage of Virtual Volumes.

For many years traditional storage array vendors have claimed that their platforms are superior for block storage than NetApp FAS because they do not have the overhead of a Pointer-based Architecture – let’s explore this in more detail:

What do we mean by “pure” block storage?

Uses a Fixed Block Architecture whereby data is always read from and written to a fixed location (i.e. each block has its own Logical Block Address) – in reality most block storage arrays provide the option to use pages (ranging from 5 MB to 1 GB) where the LBA is fixed within the page, but the page can be moved to facilitate tiering.

The advantages of this architecture are:

1. No performance overhead – it is very easy for the storage array to calculate the location of a block and there is no metadata to cache
2. No capacity overhead – as there is no additional metadata to manage
3. No fragmentation – blocks always remain together which enables good sequential IO performance on HDDs
4. Lends itself to tiering – to automatically place data on the most appropriate drive

The disadvantages of this architecture are:

1. Advanced data services – cannot be supported:
   1. Granular De-duplication, Compression and Thin Provisioning – typically 4K-32K
   2. Low-overhead snapshots – using Redirect-on-Write rather than Copy-on-Write
   3. Hypervisor technologies like Virtual Volumes (VVOLs) – as VMDKs need to be stored as objects/files
2. Write performance overhead – especially when using parity RAID (i.e. R5 or R6)
3. Replication performance overhead – when based on snapshots (as snapshots have a significant overhead)
4. Separate block and NAS – NAS requires a separately managed file system to be laid on top of the block storage

How does NetApp FAS compare?

FAS uses a Pointer-based Architecture, utilising 4K blocks which can be located anywhere, called WAFL therefore we have to reverse the above list of advantages and disadvantages. NAS based file systems are delivered along with block storage on top of WAFL – block protocols do not sit on top of the NAS protocols instead they interact directly with WAFL.

The good news is that WAFL has been around since 1993 so it is a very mature and highly optimised technology – retrofitting advanced data services to a “pure” block storage array is not straight forward and requires major re-engineering work.

So which is best?

Well we can debate this endlessly and clearly depending on your use case one may be a better choice than the other – 5 years ago this was a valid debate, but to be honest it is a moot point as today all storage platforms have to support the advanced data services listed above and therefore need a Pointer-based rather than Fixed Block Architecture.

Let’s explore some examples of this:

• VMware
  • Virtual SAN – version 2 will include the Virsto Pointer-based Architecture to enable RoW snapshots and clones, and moving forward many more of the advanced data services
• EMC
  • VNX/VNXe – uses an 8K Pointer-based Architecture to provide RoW snapshots, De-duplication, Compression and Thin Provisioning
  • XtremIO – uses an 8K Pointer-based Architecture to provide RoW snapshots, De-duplication, Compression and Thin Provisioning
  • VMAX3 – uses 128K tracks to provide RoW snapshots and Thin Provisioning, and in the future support for VVOLs
• HDS
  • HNAS – uses a 4K/32K Pointer-based Architecture to provide RoW snapshots, De-duplication and Thin Provisioning
  • VSP G1000 – the new Storage Virtualization Operating System (SVOS) was built with VVOLs in mind

It is also worth pointing out that all of the start-up storage vendors that have come onto the market in the last 5 years do not have “pure” block storage platforms – it would just not make sense if they did.

What is interesting is that NetApp do have a “pure” block storage array – the E-Series which provides excellent price/performance, but it lacks the advanced data services enabled by WAFL – also VVOLs support is not expected for some time.

So for me “pure” block storage is no longer sustainable and dismissing products like NetApp FAS because they are not “pure” block no longer makes sense. Moving forward the issue is not that your storage platform has a ground-up all-flash design, but does it have a ground-up Pointer-based Architecture.

“Pure” block storage is dead – long live WAFL and the like.

What is most valuable?

How has it helped my organization?

For how long have I used the solution?

What was my experience with deployment of the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and technical support?

Which solution did I use previously and why did I switch?

How was the initial setup?

Which other solutions did I evaluate?

What is our primary use case?

What is most valuable?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and support?

How would you rate customer service and support?

Which solution did I use previously and why did I switch?

How was the initial setup?

What other advice do I have?

What is our primary use case?

What is most valuable?

What needs improvement?

For how long have I used the solution?

What do I think about the stability of the solution?

What do I think about the scalability of the solution?

How are customer service and support?

How was the initial setup?

What about the implementation team?

What's my experience with pricing, setup cost, and licensing?

What other advice do I have?