Still no support for FC in vFilers?

[dejanliuit]

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?

[scottgelb]

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.

[shaunjurr]

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.

[radek_kubka]

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

[shaunjurr]

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.

[radek_kubka]

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.

[shaunjurr]

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...

[dejanliuit]

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.

[scottgelb]

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

[shaunjurr]

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...

[scottgelb]

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

[shaunjurr]

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.

[radek_kubka]

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.

[shaunjurr]

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.

[scottgelb]

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

Typos Sent on Blackberry Wireless

[scottgelb]

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

[shaunjurr]

Ok. Let's agree that the marketing idiots didn't give the DataMotion (vs. Data Motion) for volumes the best name.

When talking about FC, only the first is relevant, it doesn't require Multistore, just a new enough 8.x, and migrating LUN's between filers is probably more than Multistore was dimensioned for.

"Data Motion" is, conversely, not supported in 8.x  (the vfiler one).  "Data Motion" was a migration (DR) mechanism pasted around volume snapmirror and packaged as "super cool" by the marketing droids. It also required you to move entire vfilers... a bit of a big hammer for day-to-day operations...

I'll stand by my definition and you can stand by yours.  As long as both 7.x and 8.x are supported, they are in a sense, valid.

[scottgelb]

Well, I do agree on the marketing names

We still use vfiler migrate and vfiler dr in 8.x... vfiler migrate has the same end result as data motion for vfilers (but the big hammer is right...the entire vfiler), and also without the 120 second guaranteed cutover so definitely not something to consider without the possibility of downtime.  It would be nice if we had full vfiler data motion support in 8.0 for the guaranteed 120 second or less migration (it will be there but we keep saying wait for 8.x...).

We also use vfiler migrate for head swaps and migrations without having to reconfigure anything other than a new root volume on the new controller.  This isn't for day-to-day, but makes it nice every 2-3 years when controllers are updated and new disk shelves are installed.  Also, the vfiler migrate -m nocopy method without snapmirror is really slick for customers with vSeries or those who want to load balance between their FAS cluster pairs.  No snapmirror needed and the entire vFiler moves with disk reassign (the vfiler must own every volume in the aggregates) it uses..not often used but has really made vSeries head swaps really seamless.

[thomas_glodde]

imho fc support for vfilers would be THE next big thing for netapp. i dont care about multitendancy, i care about vfiler migration. I could finaly totaly abstract the logical vfiler unit from the given hardware, eg i could move my vfilers and luns from a fas3240 up to a fas6280 without downtime.

It would turn netapp into the next vmware.

ESX Servers -> NetApp Heads

Virtual Machines -> vFilers

Datastores -> Aggregates (like in VMware, Datastores may be attached to certain ESX Servers only and i could do a storage VMotion)

but thing is, thats the way ontap 8 cluster mode is supposed to be in the future, so i wouldnt exactly count on having fc support for vfilers anytime soon in ontasp 8 7 mode.