Are fabric services protected?

[j.sargent]

Are fabric services in VSAN X protected against CPU hogging from VSAN Y? In other words, if an HBA in VSAN Y starts going crazy and does 2000 FLOGIs in a couple of seconds, will the login service in VSAN Y peg the CPU and possibly deny (or severely diminish) service to fabric services in other VSANs? Or is there some sort of %CPU limit for each VSAN...? I want to guarantee that my Windows vsan never causes problems for my business critical AIX vsan. In my experience, most problems with storage networks are HBA "brown-out" failures like I mentioned above (it doesn't die, just goes crazy).

Also, does Cisco publish any SAN design Best Practice docs?

[mrfrase]

I had asked engineering to comment on the FLOGI's, here is response from Umesh:

For a given feature we will control the CPU hogging but not on a VSAN basis.

For FLOGI's in all the VSANs we have a single process. We will do some throttling if too many FLOGI's come but not on a vsan basis.

As for Best Practice docs, we have some great docs in this area going through review, you will beable to get these docs via your Cisco Storage SE rep. Online documents availiable onn Cisco,com can be found at:

http://www.cisco.com/en/US/customer/products/hw/ps4159/ps4358/prod_white_papers_list.html

[plowden]

VSANs share CPU resources, so theoretically an event in one VSAN could indirectly affect other VSANs, although I haven't seen this in practice, since the CPU scheduling algorithm enforces fairness. Switching would not be impacted, since it's done in hardware. Other vendors' currently available switches would be more affected, since their CPUs are an order of magnitude slower than the MDS CPU. Plenty of customers are running separate VSANs without any issues like this.

Below are a couple of Cisco marketing links with best practices, case studies, etc. (mostly for storage):

http://business.cisco.com/prod/tree.taf%3Fasset_id=104250&public_view=true&kbns=1.html

http://cisco.com/en/US/partner/netsol/ns340/ns394/ns224/networking_solutions_packages_list.html

[j.sargent]

Thanks for the feedback guys. It would be great to have some sort of documentation about how all of this works (ways the MDS platform mitigates the risks of having only a single physical fabric). I LOVE the advantages VSANs provide for customers, but occassionaly an OSM SE will cast enough doubt so that the customer isn't confident with the design.

For example, Cisco's collapsed fabric design with VSANs is awesome, but good luck telling that to an OSM engineer who still treats an MDS like a Brocade or McData switch. Without being able to show (technically) how the MDS mitigates the risks of having a single physical fabric, we're all at the mercy of a few un-knowing OSMs and the full potential of the MDS platform will unfortunately not be used for the customer's benefit.

The MDS switches are awesome, but I'll get off my soap-box now...

[mrfrase]

We work very close with training all OSM engineers on all the features and funtions of MDS, how product works, how to configure, how to monitor and maintain. OSM have within there departments teams of people who test funtionality and qualify the solution, they also understand MDS engineering. Best thing to do is work with local Cisco Storage SE and invite this Cisco expert to educate OSM SE and customer on the MDS switch at time of sales pitch, they are waiting for your call.