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
Your environment, as you've described it, doesn't look like it needs seperate VSAN's
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.
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 :-)
This document will provide screenshots to outline the steps to setup
TACACS+ configuration to ACI and also the configuration required on
Cisco ACS server. Please find the official Cisco guide for configuring
TACACS+ Authentication to ACI:
Is it supported or NOT supported? It's a frequently asked question.
Before APIC, release 2.3(1f), transit routing was not supported within a
single L3Out profile. In APIC, release 2.3(1f) and later, you can
configure transit routing with a single L3Out pr...
Cisco Documents are usually accurate, but when it came to the document
on Cisco APIC Signature-Based Transactions it was slightly off the mark.
This document is for those novices to API like me who cant seem to
figure out how to go about performing signat...