Just to make sure I understand your layout then, you have four switches, with one active VSAN on each switch. Switch 1 is ISL'd to switch 9 and switch 2 is ISL'd to switch 10. And this infrastructure supports one DMX-4 and one NS-40G?
If this is correct then you may not be able to achieve the configuration you want as I don't believe you can create zones across VSANs. Think of a VSAN as a virtual fabric boundary: all the host and storage ports in a VSAN share the same logical infrastructure and can be zoned to each other as needed. What you may need to do to accomplish your desired configuration is to merge the VSANs in each pair of switches so that you have two VSANs in your infrastructure.
Unless you have a specif reason why you created this many VSANs I see no reason why one VSAN on each fabric would not be able to support your arrays and hosts. You want to limit unnecessary traffic, but remember this is a switched fabric and host specific traffic is going to be limited to the members of it's zone. The hosts in the VSAN will all share the common fabric services, but I don't think this will impact your environment unless it is particularly large or burdened with excessive i/o.
You could use Inter-VSAN Routing (IVR) but unless you require it I think it would create an unnecessary layer of complexity to your environment.
AranH poses some good questions. I think the key to understanding this is understanding what exactly VSANs are and what you want to achieve in your configuration. You may want to read through some information in the MDS Cookbook on VSANs to get a better understanding. They are very similar to VLANs in the IP world.
It may be easier for you to create a VLAN for all these connections that is the same on each switch and put all the ports into it. As was stated, IVR should only be used where absolutely necessary as it adds complexity and possible other bugs. I'm a big believer in the power of separating things out by VSANs where it makes sense but it can be over done also.
Are these connections something you plan to keep up permanently? Are you using them for migration purposes? Is this for backup solutions? etc. Any additional details you can provide would be helpful.
Unless there's a need for having separate VSAN's, such as long distance, I'd put all the storage ports in the same VSAN. So on 1 fabric (VSAN) everything in VSAN 100 or so and on the other fabric everything in VSAN 1100 or so.
Hosts connecting to the storage ports should also be in those same VSAN's. Each VSAN has a database which holds aliases, zones and the zoneset(s).
If you're crossing long distances and want to eliminate unwanted merges and splits of your fabric, which cause RSCN's, create separate VSAN's on each side of the and use IVR to connect the VSAN's together. If the link goes down, the original VSAN's on each side won't suffer other than loosing their connection to the remote side.
healyj
141 Posts
0
November 28th, 2017 06:00
Hi there,
In our effort s to clean up the forum, we came across your question / statement.
If the question / statement is still valid, not expired and you need an update please reach out again and we try to get it answered.
As for now we set it to “answered.”
Regards,
Jim
AranH1
2.2K Posts
0
September 8th, 2008 09:00
If this is correct then you may not be able to achieve the configuration you want as I don't believe you can create zones across VSANs. Think of a VSAN as a virtual fabric boundary: all the host and storage ports in a VSAN share the same logical infrastructure and can be zoned to each other as needed. What you may need to do to accomplish your desired configuration is to merge the VSANs in each pair of switches so that you have two VSANs in your infrastructure.
Unless you have a specif reason why you created this many VSANs I see no reason why one VSAN on each fabric would not be able to support your arrays and hosts. You want to limit unnecessary traffic, but remember this is a switched fabric and host specific traffic is going to be limited to the members of it's zone. The hosts in the VSAN will all share the common fabric services, but I don't think this will impact your environment unless it is particularly large or burdened with excessive i/o.
You could use Inter-VSAN Routing (IVR) but unless you require it I think it would create an unnecessary layer of complexity to your environment.
ConnectrixHelpe
259 Posts
0
September 8th, 2008 10:00
It may be easier for you to create a VLAN for all these connections that is the same on each switch and put all the ports into it. As was stated, IVR should only be used where absolutely necessary as it adds complexity and possible other bugs. I'm a big believer in the power of separating things out by VSANs where it makes sense but it can be over done also.
Are these connections something you plan to keep up permanently? Are you using them for migration purposes? Is this for backup solutions? etc. Any additional details you can provide would be helpful.
Thank you.
RRR
4 Operator
•
5.7K Posts
0
September 17th, 2008 03:00
Hosts connecting to the storage ports should also be in those same VSAN's. Each VSAN has a database which holds aliases, zones and the zoneset(s).
If you're crossing long distances and want to eliminate unwanted merges and splits of your fabric, which cause RSCN's, create separate VSAN's on each side of the and use IVR to connect the VSAN's together. If the link goes down, the original VSAN's on each side won't suffer other than loosing their connection to the remote side.