CDOT == Vista ?

Am I the only one thinking that CDOT is NetApp's Vista (or Win8)?

I do see some good things about CDOT, but nothing is feature complete.  And the CLI interface is tab completion, lacks syntax documentation.

As for the movement, it still mostly disruptive, and can only be done on a volume by volume basis.

I would have thought that the movement should be at the volume level on the lowest echelon, but should apply to the vserver to make it really usable.  The lack of application group identification is also another feature which should have been there.  I should be able to group my volumes by vserver/app or app-group, and should be able to perform mass-moves as such.  What use is being able to move individual volumes around?

And in reality I see two tiers of storage these days, SSD, and SAS 2.5".  Both are ultra low power, faster than SATA, and I bet they are cheaper over the long run than the power hog 3.5" SATA's.  So there are really two tiers?   I'm just saying...

I just don't know that there is any real value in CDOT for the average user.

I think NetApp should have continued development of 7DOT, adding SMB 3, pNFS (soon), and the non-disruptive volume migration.  And they should have kept the 7DOT CLI.

Am  I off-base?

Re: CDOT == Vista ?

Full disclosure... I work for NetApp.

I wouldn't call cDOT "Vista"... maybe more of a Windows 7, or even Windows 8. It would be fair to call GX "Vista," I think.

There are value adds in cDOT that you don't get in 7-mode, even for the most basic admins.

For instance, in 7-mode, could you have 4 nodes in a single namespace? No... if you wanted to add CPU or RAM, or even disk (if you maxed out your HA pair) you had to add a whole new HA pair with new IP addresses, new folder structure, etc. Then you had to tell all your users "hey, mount this AND this."

With cDOT, you don't have to tell your users anything. You simply add new nodes non-disruptively and provision storage under the same namespace/vserver/SVM. That's it. No new IP addresses, no re-mounting, no communication with your users about downtime.

What admin wouldn't want THAT?

As for movement, you are forgetting about aggregate relocation (ARL), which allows you to move entire aggrs non-disruptively. Did 7-mode have that?

In 7-mode, you could move volumes... between two nodes. But what if both of those nodes are slammed? In cDOT, I can add more nodes (up to 24 in NAS) and move the volume to a node that isn't being used at all.

There are definitely use cases for application/group based volume moves, and I suggest you speak to your sales representatives to put that sort of thing on the radar for the product managers, if it isn't already on the radar.

For your point about disks/spindles, there are still use cases for high capacity, low RPM SATA drives - many customers still use this type of disk for backups, archival, etc. And with different disk types on separate HA pairs, service providers can sell tiered storage to their customers. You want faster storage? You pay a premium. You want economy storage? You get the SATA drives!

7-mode would never be able to properly leverage features like pNFS, which is one reason why you won't see it in 7-mode. What point is there to a protocol that is built for highly agile, mobile storage in a single namespace on an OS that is limited to two nodes, each with their own namespace?

Things like CLI, feature gaps, etc... those are all valid concerns and things I have rallied for improving behind the scenes. Changes are coming. 8.3 will be a major improvement over 8.2. And later releases will introduce even more feature parity and usability for everyone.

Re: CDOT == Vista ?

Thanks for the reply Parisi. 

You make some good points.  However, from my perspective it is still a half baked product, since it will not allow me to perform online group/app moves.  What is the difference between moving an applications volumes in 7DOT, one at a time, versus CDOT, one at a time also.

As for shelf replacement, from what I've been told, it is a little more marketing.    The reason I say that, is that if I have a shelf that has become stuck, which I've had happen many times, the only way to clear it is to power off the entire stack.  That means, having enough extra disc stacks to move the data on the stack which is failing, plus enough bleed-over space for each aggregate in the failing stack allocated in other stacks.  I usually don't have stacks of shelves sitting unused, so I will still need to take an outage.

I was not aware of the aggregate relocation, that is an awesome feature.  Sort of what I want with volume/app groups.

Perhaps I maybe wrong;  I have been trying to get a CDOT vSIM cluster setup since the beginning of they year and have had no luck.  I may very well change my mind once I can start playing with the cluster.

HOWEVER, the CLI... ...and the changes to the CLI interface make learning CDOT onerous.  I'm glad to hear that 8.3 will improve it.

Thanks for responding and giving me ideas about features to investigate, once I have a cluster setup.  Perhaps others will chime in and help me understand CDOT better.

BTW, a shameless plug, the "NetApp Communities Podcast" has been a tremendous tool for learning about CDOT features.  I get it on iTunes, but I believe it is available elsewhere as well.  (And no, NetApp, do not take it over, leave it semi-independent as it is).

Thank you

Re: CDOT == Vista ?

There are plenty more features that make cDOT an improvement over 7mode. I just mainly listed the ones that addressed your overall concerns.

For shelf issues, there is a feature called "hot shelf removal" (added in 8.2.1) that can be used in conjunction with aggregate relocation to allow you to power cycle, remove shelves, etc.

To read more:

For 7-mode veterans, yes, the CLI is a challenge. But the feedback I have heard from users who never touched 7-mode is that the cDOT CLI is easy to use. In 8.2, there were improvements made to the man pages on-box, too. So if you ever had questions about a command, just type "man [command]" and you'll see all the info.

Additionally, rather than using tab completion, you can leverage ? to get listing of available values for a command option. There are plenty of tricks and tips for cDOT CLI.

8.3 won't necessarily completely improve the CLI, but it will further converge the 7-mode features and commands into cDOT. Even now, you can run 7-mode like commands in cDOT (such as df, sysconfig, etc) in the cluster shell.

Go ahead and install the simulator and test it out. The more you use it, the more you will see the advantages over 7-mode.

Re: CDOT == Vista ?

For shelf issues, there is a feature called "hot shelf removal" (added in 8.2.1) that can be used in conjunction with aggregate relocation to allow you to power cycle, remove shelves, etc.

Are you sure it is aggregate and not volume reallocation? To hot  remove shelf it must be empty which means all data must be evacuated and aggregates on this shelf destroyed. Aggregate relocation changes ownership but not physical placement; to evacuate data one would need to move volumes off to another aggregate.

Re: CDOT == Vista ?

What use is being able to move individual volumes around?

So you can utilise different I/O performance tiers and network paths within a given vServer..

cDOT is good because it dissassociates vServers from physical controllers and aggregates and allows you can access resources across the whole cluster via a single namespace.

Personally I would never want to move a whole vServer or application group from "A" to "B" in one go except for very small vServers (one volume) while rebooting node. Thinking about a vServer as a unit of storage which needs to be put somewhere and moved around as single entity is contrary to the way cDOT is designed to work IMHO. The way I see it, a vServer is primarily a namespace and security realm, rather than a storage object.

Re: CDOT == Vista ?

Yes, you are correct. Brain fart.

Re: CDOT == Vista ?

Think of it this way... 8.0 and 8.1 were the alpha and beta releases... thus Ontap "Cluster Mode" the rename to CDOT came with the live production release of 8.2, and we have seen SP1 come out already, with 8.2.1, and are working our way toward the next major release.

There are many wonderful features in CDOT that are impossible in 7 mode, many are similar to what other major storage vendors are doing, and many are revolutionary. I see it as a real step forward.

Re: CDOT == Vista ?

Here are some comments from a customer perspective.

The CLI in CDOT is incredible once you get acclimated to it and it really doesn't take that much time.  I was so used to administering everything from a linux host via SSH so I could get an extra set of tools like grep to supplement.  Now I prefer to be consoled directly in because of the tab autocomplete capability.

The migration from 7-mode to CDOT wasn't without pain.  The 7MTT was helpful but was far from perfect as of version 1.2 at least which is what we completed our transition on.  It's great at getting the volumes mirrored from 7-mode to CDOT so you're data is all intact.  The access to the data, which is pretty critical, is a different issue.  We ran into a decent number of gotchas in regards to access after the transition.

Here are some from our experience:

  1. We had cifs shares where the case of the folder name in the path DID NOT match the case of the actual folder.  7-mode didn't care, but CDOT is not forgiving of such.  7MTT did not warn me of this and the result of 81 cifs shares not being recreated on the CDOT side during the transition.  I was fortunately able to identify all of these shares from the logs of the tool noting the share could not be created.
  2. Crucial to have an understanding of junction paths and how much different it is compared to 7-mode /etc/exports.
  3. Per KB 3011859, we have qtrees w/ NTFS-style ACLs that are accessed from linux servers.  The KB doesn't provide any method for resolving the issues described for CDOT.  I had to scour the documentation to find the equivalent workaround which is hinted in the 7-mode to CDOT options map write-up.
  4. Inability to NFS export at a qtree level until 8.2.1 which delayed our migration for some time until it went GA and we upgraded to it.  One issue you won't have to deal with at least.

Overall, the transition pain is worth the benefits of being on CDOT in my personal opinion, but we have a relatively small environment compared to other companies (just two physical nodes).

I personally installed the CDOT simulator before any planning in order to get a feel for the new CLI and also learn how the commands map.  It helped tremendously.

At this point, we're mainly still getting reports here and there of NTFS data being accessed from linux hosts failing, but I believe I've discovered all of the fixes and workarounds for the different types of circumstances surrounding these and have been able to resolve as they are reported.  The user mapping piece in general is just as confusing as it was in 7-mode for NTFS/UNIX.

Re: CDOT == Vista ?

You are not alone.  

The only CDOT feature that is of interest is the promise of non disruptive cluster pair upgrades when heads and disks go EOL.  However, the level of effort and time required to migrate/convert 2PB and 35 HA pairs to cluster mode doesn't seem like its worth the effort or risk.   Specially with Mars on the horizon.

Here's a few CDOT concerns

   7mode to CDOT migration:  Migrating from 7mode to CDOT is about the same level of effort as moving from 7mode to Isilon.    The 7mode migration tool has helped, but still hearing of gotchas and SMB issues.

   Workload isolation:    Currently we have isolated our 7mode workloads into HA Pairs.   HA pairs for each of Oracle NFS, VDI, Vmware, Backups, SMB, etc. This physical isolation has worked well for performance, manageability, and most important politically.    We have considered using a single CDOT cluster for all the workloads, however isolation seems like it's going to be an administrative challenge.     Now considering multiple clusters based on workload type, aka 7mode physical isolation.

   Naming conventions: It was hard enough in 7mode, but CDOT with all its logical and physical objects adds a whole new level of complexity.    Fortunately, most everything including the cluster name can be renamed on the fly.   We must have renamed our test cluster and SVMS 5 times now, and still don't know what to name the SVMs.   Can't tell you how many needless hours spent debating unix host naming standards in the past.   Try debating a system that needs 20 different object names.

   Namespace:  Again, a whole new level of trying to design a standard namespace.   Get this naming wrong, and live with it forever.    So far, everyone wants a flat namespace with no sub levels which seems like it's going to be a mess down the road one way or the other

   CDOT upgrade path:  The marketing folks are saying non disruptive updates.   Adding new nodes to a 2014 CDOT in 2018, yea right.  I'm sure the exception list will be 4 pages long, and most likely not supported. 

   SMV: How many, what to name them, how to isolate aggregates to prevent other SVMs from using isolated heads.   It would be cool to be able to snapmirrow at the SVM level.

  Performance Monitoring and metrics.   A whole new way to monitor CDOT and a limited performance metrics available in CDOT.    The promise of non disruptive volume migrations is of little use when you don't have metrics needed to make decisions based on performance.   Work in progress I guess.

  CDOT SAN.   Wow, yet another level of complexity.   SAN is bad enough on its own.

   Performance?     Still haven't seen performance marketing stats...   Does CDOT perform better than 7mode for the same workload?   Maybe I missed those marketing slides.

CDOT seems extremely flexible and a great foundation for creating things like flexpods where you need a great deal of flexibility for features like multi-tenancy.    But way to complicated for shops that are just needing SMB and NFS shares and maybe even iscsi with minimal administrative knowledge and short on staff.

CDOT broke the KISS rule,  same as VISTA.    Maybe just wait for Mars to rise.