Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

To VSAN or not to VSAN that is the question

So in a DC I have two unique storage frames, VendorA and VendorB.  There is no replication taking place between these two devices.  I have set this up using two VSANs, VSANA and VSANB. 

There has been some discussion that this is unnecesary and we shouldn't do it.  I don't see why you wouldn't isolate them to prevent any potential issues or overlap. 

Thoughts?

3 REPLIES
New Member

To VSAN or not to VSAN that is the question

Having done SAN's for some time, and long before VSAN's were invented - I also struggle with this question sometimes.

I'd look at it like this.  Do you have a reason where you HAVE to make sure the arrays are seperated?  If not, I wouldn't bother with the extra complexity of VSAN's (yes, they arn't that complex, but it is another layer to admin).

As an example, I would tend to seperate the following into different VSAN's:

Open System Disk

Open System Tape

FICON Disk

FICON Tape

Your environment, as you've described it, doesn't look like it needs seperate VSAN's

Steven

New Member

To VSAN or not to VSAN that is the question

Its all an interesting topic and trying to make sense of it all.  I have always done the VSANs so that we have that added layer and it wasn't a problem.  THere was a question about it and wanted to get a few opinions.

Cisco Employee

To VSAN or not to VSAN that is the question

Hi Guys,

i'd like to add my 2 cents here. 

Here's a rule of thumb I use for desiging VSAN layout:

"Put N-ports that *should not* be communicating with each other in separate VSANs "

The important part here is "should not".  for instance, Ficon Tape environments shouldn't be communicating with Open Systems's hosts.

This isn't the same as putting things that should be talking to each other in the same one.  For instance, maybe you have a Production and a Acceptance storage array.  they 'Should Not' be talking to each other, so you'd put them in separate VSANs. 

Except maybe you want a periodical copy of old production data to your acc environment, to do realistic acceptance tests. So you could argue that you 'Should' put them in a same VSAN.   IVR is a much better fit here.

I know this is fuzzy, so I'll give another example:

Primary Datacenter Storage and its hosts are in one VSAN, and Backup DC Storage is in another, because hosts from PDC 'Should Not' be talking to the storage in BDC.  

But you want replication. Again, IVR would be a good match here, using a Transit VSAN between the 2 dc's.

However here it would be acceptable to put your replication ports in a VSAN and just forget about IVR all together, simplifying your design.

The key in the second example is that replication N-ports and front-end N-ports aren't shared.  But for the first example, this can be a host copy so the N-ports are 'shared', hence IVR is better.

You can see that the examples put forth by Steven match this rule.

To answer jlefko's question:  I think you have plenty of isolation between your devices using zones, and it's not unthinkable some of your hosts might migrate from VendorA to VendorB or vice versa.  It's not like they 'Should Not' be talking to both A and B, there's no prohibitive technical or business rules in place.

So yeah, a single flat VSAN will do fine in your case :-)

Hope that clears things up a bit!

/Kris

373
Views
0
Helpful
3
Replies
CreatePlease to create content