cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
348
Views
0
Helpful
5
Replies

Please help me with my Zones

nathannellans
Level 1
Level 1

I have inherited our storage infrastructure and I'm trying to clean it up.

I have a Cisco 9140 connected to SAN 1. I have another 9140 connected to SAN 2. The two switches are connected via an extended ISL.

All of our hosts connect to Switch 1. If they need to access data on SAN 2 then they traverse the ISL over to Switch 2.

My question is as follows. For a host which only accesses data on SAN 2, what members do I need to have in the zone? Here is what is currently in the zone for a host accessing data on SAN 2.

1. Both SAN controllers for SAN 1

2. Both SAN controllers for SAN 2

3. HBAs for the host

Do I need to have the controllers for SAN 1 included in the zone even though it does not access data on SAN 1?

5 Replies 5

Michael Brown
Cisco Employee
Cisco Employee

If you are using the same VSAN for both switches and that VSAN is extended across the ISL, you really have only 1 SAN. (with 2 switches).

I would think that the only zone members you need in your scenario are Host HBAs and both controllers for SAN2. If the controllers have access to the same back end disks, there may be a need to have the controllers for SAN1 in the zone in the event that the controllers ever export the disks out the controller for SAN1. If these are 2 unique arrays and the disks will never be mapped to the SAN 1 controller, then there is no need to have it in the zone with the HBAs and SAN2 controllers.

Hope this helps,

Mike

Mike, thanks for the info. I have configured the zones to only have the controllers for whatever SAN holds the data, instead of just including all controllers for both SANs. I activated the zoneset and everything is working great!

Nathan

inch
Level 3
Level 3

G'day,

Generally you would zone each port on a hba (the initiator) to any storage controller port (the target).

If you have inherited this small SAN it might be worth doing a little audit across it to ensure it is setup in the most redundant and performance optimised way available.

The Cisco 9140's are generally used as "host optimised" edge switches.

"hot optimised" means that 32 of the ports within the switch are "oversubscribed" which means there is a total 2.5gb of bandwidth for a group of four ports.

There is a group of 8 ports (on the left hand side) which are non-oversubscribed which are generally used for targets (storage controllers) or ISL uplinks to other switches.

So, you might want to make sure your targets (two storage controllers) and ISL's are plugged into these non-oversubscribed ports - If they are not, you will have to perform an outage to fix this.

The second thing to check is to ensure more than one port is configured as an ISL and "bonded" together as a port-channel. This allows redundancy in case a link fails and also increases the available bandwidth for the ISL.

Third of all you will need to check to ensure all your hosts are dual pathed/homed/connected to the switch. This also adds redundancy in case of HBA and link failure (You will need to ensure your hosts are also running multipath software to utilise the two links).

And finally (I know this is getting a little long winded now!) read up on VSAN's (virtual SAN's). VSAN's are great and allow you to have another level of redundancy within your environment.

Hope this helps!

Cheers

Andrew

Andrew,

Thanks for all the info. I have been dealing with the SANs for a few months and did enough research and testing to be dangerous. But, I just recently dug into it deeply. Our environment seems like it was setup pretty well. There's just a lot of little things to clean up.

I was aware of the importance of the first 8 ports on the 9140 switches. We have our controllers, ISLs, and our Blade switches plugged into them. The regular hosts are all plugged into the other 32 ports.

We do not have bonded ISL's. We do, however, have dual fabrics (4 switches total). So if an ISL on one fabric goes down, at least we have another fabric which works.

We have dual HBAs in each of our servers. Each HBA goes to a different fabric. And multipathing software is installed in each client as well. I have been upgrading the multipathing software so that we can upgrade our controller firmware. Once the firmware is updated, we can switch to using the MPIO multipathing.

As far as VSANs, we only have 1. I'd like to keep it that way to keep things simple. We only have our SANs on the fabric anyways, so I don't see a need to segment it.

Thanks for the tips. It was nice to see that our environment seems to be setup in a decent way.

Nathan

G'day Nathan,

Good to hear!.. I would probably raise a change request to get your ISL's created as a port-channel and seriously think about using a different vsan number than the default (1).

I know its only a small SAN but it really important to get these types of things correct initially as it will make migrations and upgrades in the future so so much easier!

Good luck with it all!

Cheers

Andrew

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: