I’ve just been reading up on Data ONTAP 8.0 as part of some ongoing work I’m doing. You may be aware that version 8.0 of the filer operating system brings two major features; 64-bit support and the (sort of) integration of the Spinnaker code to create the multi-node version of ONTAP (called cluster mode).
The move to 64-bit is an essential feature required to enable NetApp filers to scale. Currently both aggregates and Flexvols are limited to only 16TB. Plenty of people have complained this limit is far too low and it is one of the most restrictive scaling issues within ONTAP. By moving to 64-bit aggregates, scalability is increased dramatically (but perhaps not proportionally as expected) to 100TB. Unfortunately things are not all rosy. For instance, although aggregates move up in size, FlexVols do not; they stay at a mere 16TB. There are a number of other things to consider that mean FlexVols are still not as flexible as they should be. For instance:
- There is no option to move FlexVols between aggregates without taking an outage. Volumes can be copied (vol copy command) or cloned (vol clone command). As volumes get larger, taking extended outages to simply move data is unacceptable. NetApp needs to add the facility to transparently move the underlying location of a FlexVol without user impact.
- Aggregate type (32-bit or 64-bit) is determined at creation time. This means a 32-bit aggregate, once created, cannot be expanded past 16TB. It also means that after a migration of an existing system to Data ONTAP 8.0, the aggregates can still not be expanded. If you’re hoping an upgrade will give you extra flexibility – it won’t. You will have to create new aggregates and migrate your data – which of course can’t be achieved without outage, as we’ve just discussed.
- A system with 64-bit aggregates cannot be reverted to a version of Data ONTAP lower than 8.0. So, think long and hard after that upgrade about whether you need 64-bit aggregates. Once you create them, they are here to stay.
- Aggregates can be increased in size by adding disk – but not reduced in size. So, there’s no flexibility in being able to temporarily increase an aggregate size, then reducing it when capacity requirements decrease (or when data has been moved elsewhere).
It’s disappointing that there are still significant restrictions in the use of so-called FlexVols with the new release of Data ONTAP 8.0 Fracturing the code into “7-mode” and “cluster-mode” doesn’t help – for instance the new vSphere VAAI extensions are not supported in Cluster Mode, so this isn’t a practical route to take in order to get the additional functionality. With the noise we hear from NetApp about virtualisation, the address space for the number and size of objects should be much larger than you wil never need. Unfortunately we are still pushing the logical limits which causes issues with utilisation and mobility, increasing operational cost.
On balance, I haven’t reviewed other NAS vendor’s products to do a full comparison here, however as NetApp are perceived to be the market leader, I’d expect more from them after nearly 20 years of development. There are other NAS products out there and I can’t help thinking that it’s only a matter of time before their market share starts to hit the NetApp bottom line.
Comments are always welcome; please read our Comments Policy first. If you have any related links of interest, please feel free to add them as a comment for consideration.
Copyright (c) 2007-2020 – Post #6C1B – Brookend Ltd, first published on https://www.architecting.it/blog, do not reproduce without permission.