FAS and V-Series Storage Systems Discussions

Highlighted

Still no support for FC in vFilers?

I find it quite perplexing the fact that Multistore/vFilers doesn't support the Fibrechannel protocol.

With so much Netapp talk about multitenancy and yet the one of the largest deployment protocols is not supported in vFilers.

I checked the OnTap 8.0.1RC2 documentation and FC is still "vFiler 0"-only.

With the NPIV feature around since 2002 (or so) in Fibrechannel it should have been quite straightforward to implement the support for vFilers since a long time ago.

On the oldest hardware you can blame the builtin chipset, but at least since 4GB/s Fibrechannel I believe all FC chipset manufacturers implement NPIV.

And Netapp could always say that FC for vFilers is supported from model xxx. There are a lot of other features that are differented between models so it shouldn't be a problem.

Now with the hardware refresh behind us, I find it even more surprising that there is no indication that FC will be supported on vFilers, no matter if we are talking 4GB/s, 8GB/s or FCoE.

Could someone explain to me if there is any obvious reason for FC with NPIV not to work (at least theoreticly) in vFilers?

18 REPLIES 18
Highlighted

Re: Still no support for FC in vFilers?

I completely agree with you.  There is no reason it wouldn't work with NPIV functionality in vFilers.  I know this is on a road map but not on one we can discuss in Communities.

Highlighted

Re: Still no support for FC in vFilers?

There is probably a fundamental misunderstanding of what vfilers are supposed to do.  Multistore exists to separate data into different "authentication domains" for network protocols.

Since you are not using LDAP/AD authentication (or pap/chap/isns/igroups for iscsi), there is really no need to push volumes into vfiler contexts, except for a cleaner looking storage picture.  vfilers have no other storage role than segregation of data (into differing authentication domains) for the network protocols. One cant prioritize traffic or resources based on vfilers...

Using Multistore to segregate data for FC luns is just overhead and costs.  There is no security advantage.

NPIV is an abstraction that is useful on the server side to enable shared utilization of FC links.  I can't really see the point of the extra work in implementing it in ONTap.  The OS already has control of the entire FC stack and the underlying storage.  You would just get another software layer that would slow things down and probably add a lot of bugs.

Highlighted

Re: Still no support for FC in vFilers?

I beg to differ.

It looks like MultiStore is a pretty key element of the so called Secure Multi-Tenancy design which is a hot topic due to the Cloud context:

http://www.netapp.com/us/technology/secure-multi-tenancy.html

http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/Virtualization/securecldg_V2.html

"Each vFiler unit can be individually managed with different  sets of performance and policy characteristics. Providers can leverage  MultiStore to enable multiple customers to share the same storage  resources with minimal compromise in privacy or security"

In the past I have heard conflicting messages re MultiStore & FC support - some NetApp folks were simply saying "who needs FC these days?", some others hinted "it is on the roadmap".

We will see how it goes!

Kind regards,
Radek

Highlighted

Re: Still no support for FC in vFilers?

The performance characteristics claim seems to be a very watered down allusion to "FlexShare" which really is totally independent of Multistore.  The statement on its face is true, but there is no causal linkage here.

FC security is the same as on any fibre channel system, no matter what the vendor: zoning and host groups/masking/igroups.  Multistore doesn't get you anything here.

I guess I wouldn't base my technical planning on the hype from marketing people.

I live just fine with no Multistore FC functionality.  I can list all of my luns per igroup and I know which customer owns the systems.  I'm glad I am spared pushing a bunch of volumes into vfilers and setting up igroups there. For FC, one would probably need something ála "ipspace" to keep the paranoid from wondering where the FC frames were wondering through the circuits.  It would just make things even more complicated than having to "soft-zone" for NPIV already.  If you have an FC only box, Mulitstore licenses would just push your costs up with no gain.

If I had a vote, I'd vote "no".  Too few gains, too much added complexity, FC has to be stable and more code means more bugs.

Highlighted

Re: Still no support for FC in vFilers?

FC security is the same as on any fibre channel system, no matter what the vendor: zoning and host groups/masking/igroups.  Multistore doesn't get you anything here.

I beg to differ again: Cisco first introduced the concept of VSANs (multiple fabrics on a single physical device) which couldn't be compared to traditional FC zoning (carving up a single fabric). As for MultiStore & FC: we don't know what it brings to the table, as it doesn't exists yet; I would expect something along the lines of VSANs though.

I guess I wouldn't base my technical planning on the hype from marketing people.

Yes, no issues with that. But many other people will have a different view & would like to follow the secure multi-tenancy "hype" - all I am saying here is that no FC on MultiStore means a gap in this concept.

Highlighted

Re: Still no support for FC in vFilers?

Well, before we get all bubbly and stary-eyed about the wonders of Cisco, Virtual SANs/Fabrics/Switches have existed for some time without the Cisco name on the equipment.

The VSAN abstraction is most certainly an abstraction that Cisco had to make (encapsulated within vlans) to insure the no-loss delivery mechanisms that FCoE required.

Really, the marketing guys have done their job, but crack open a book on FC or just an administrators guide from Brocade, and the reality looks a lot different...

Highlighted

Re: Still no support for FC in vFilers?

Not going down the multitenancy discussion, you have Ontap features that require vFilers to work.

Today it is Ontap "Data Motion", tomorrow who knows.

So today the "Data Motion" feature is a no-go for FC-users for no obvious technical reason, at least for me.

It might be a priority question, but that then puts a question on Netapps strategy regarding FC/FCoE.

Highlighted

Re: Still no support for FC in vFilers?

Agreed. Data Motion, vfiler migrate, vfiler dr, would be a nice addition to fc.. And it will as we converge down the road with cmode vservers.

Typos Sent on Blackberry Wireless

Highlighted

Re: Still no support for FC in vFilers?

Data Motion does not require Multistore.  It only requires that if you use Multistore, the volume (LUN) is managed by vfiler0.

This makes it easily usable for FC consumers.

Your post is either unclear or incorrect.

Highlighted

Re: Still no support for FC in vFilers?

FC doesn't really need vfiler migrate, per se.  I guess I object to overloading a concept that already does what it is supposed to.  It was designed for virutalize disk resources over different authentication domains for NAS storage. I don't think NetApp has any advantages in cutting up ONTap to run "logical domains" or "virtual filers" more than Multistore does now, in any case, not just so that FC storage "seems like" it belongs to the same customer because it is in the same vfiler.

I would be infinitely more excited for something like what Spinnacker did before NetApp sort of killed them by buying them (GX has taken years to become more than a niche product).  We need to be able to move LUNs (and for that matter all NAS resources) between controllers (and not just aggregates) without downtime (no, CIFS isn't there yet).  This is "High End" FC storage. Data Motion is the first step.  More FC abstraction is needed or more "scale out" possibilities to be able to migrate between multiple contollers... or from old to new...  but I degress...

Highlighted

Re: Still no support for FC in vFilers?

Data Motion does not require Multistore.

That's partially true, as there are two flavours of Data Motion:

- for vFilers, moving them between HA pairs, working for NFS & iSCSI

- for Volumes, moving them between different aggregates behind the same controller, working for FC, FCoE & iSCSI

http://communities.netapp.com/docs/DOC-9649#

So two different things really, with very different scope.

Highlighted

Re: Still no support for FC in vFilers?

I am well aware of this topic. Data Motion for vFilers... Data Motion for Volumes is different. Data Motion for vFilers, vfiler migrate and vfiler dr need MultiStore.. Period..

Typos Sent on Blackberry Wireless

Highlighted

Re: Still no support for FC in vFilers?

DataMotion and  Multistore Data migration are only remotely related by their use of snapmirror.

My contention was 100% correct.  "DataMotion" as a NetApp production/functionality does not require Multistore.

Highlighted

Re: Still no support for FC in vFilers?

Data Motion for vFilers absolutely requires MultiStore. The 8.0 data motion for Volumes is entirely different.

Typos Sent on Blackberry Wireless

Highlighted

Re: Still no support for FC in vFilers?

Many customers have requested fc support in vfilers. For no downtime migration between controllers, to delegate management, to automate igroups and lun mappings, to have single command dr for an entire vfiler (instead of having to break 50 mirrors and manually or script create igroups and map luns), to vfiler migrate without snapmirror between cluster nodes or vseries neighborhoods (-m nocopy formerly called snapmover).

We won't see support for this until vFilers converge with vServers. Meanwhile, it is nice that we can both vFiler migrate between controllers and also volume move (data motion for volumes) with luns between aggregates.. I do wish 7-mode supported nas for vol move like gx/c-mode..but that will come down the road.

Typos Sent on Blackberry Wireless

Check out the KB!
NetApp Insights To Action
All Community Forums