Welcome to this Ask the Expert discussion. This session will address the topic of “SAN (Connectrix), FC Connectivity Recommendations and Best Practices". We will discuss best practice in storage networks FC networks (SAN) with the goal to obtain better performance and optimal configuration. In addition, we will answer questions about administration, planning and SAN configuration.
Meet Your Expert:
Sr Field Support Engineer - EMC Spain
Felipe joined EMC in 2005 working as Customer Engineer. Since then he has performed different roles within the company (CE, MLS, S&D) and in 2010 he became part of the EMEA FSS community as Infrastructure connectivity specialist. Some of the products Felipe has experience with are: Connectrix, Cisco, Brocade, CLARiiON, Symmetrix, VPLEX, RecoverPoint, EMC Proven Specialist, Performance vSPEED.
This discussion takes place February 2 - 22. Get ready by bookmarking this page or signing up for e-mail notifications.
Alejandro también esta contestando preguntas en español sobre este tema, si prefieres hacer preguntas en este idioma dale clic a este vínculo: http://bit.ly/1zFiMS0
Share this event on Twitter or LinkedIn:
Welcome to our newest ATE session on ECN. We'd like to open this discussion for replies. Let's make of this an opportunity to respectfully engage our experts with your questions, comments or ideas. Have a great experience!
First off thanks for your query. The fact is that, although this feature is pretty useful, not many customers use it: mainly customers with a big SAN to manage take the step to introduce Smart Zoning.
For those of you who are not familiar with the concept of Smart Zoning, the following link provides a nice description of this feature introduced by Cisco in NX-OS 5.2(6).
By using Smart Zoning, the size and manageability of zonesets can be drastically decreased, specially when using clusters that share targets (storage ports) among several Initiators (server HBAs). With Smart Zoning, you can configure a single zone containing all the Initiators and targets in the same cluster (eg ESX farm) and the switch itself prevents the Initiators from seen each other even though they're in the same zone.
I don't have a big SAN (one 9513 core and a few 9148 edges) and i have been using SmartZoning for 2 years now. It is the best thing that has happened to zoning in a long time . It was very easy to enable SZ on a running VSAN too, "traditional zones co-exist with SmartZones in the same zoneset just fine.
a customer has upgraded to FOS 7.x, and needs to know if, with the new version, they still need to take care to manually config the parameter fillword to value = 3.
Good evening Manu,
That's a good one, because there is a little bit of confusion with it. The answer to that question is:
The fillword is a FC primitive [in plain language, pre-defined frames] used to keep the link synchronized. It became renowned when Brocade introduced the family of switchs that supported 8G. When working at 8G, the FC standard states that the fillword to use is ARB (whilst previously it was IDLE). With 8G Brocade products, this fillword has to be manually configured and when Brocade released the new set of 16G switchs, the fillword is automatically configured, so in a few years time, we will forget about this parameter and live happily oblivious again.
When it comes to EMC products, the recommendation is to configure the fillword with a value of 3 when working at 8G.
What is the main benefits of using ISL trunking?
How does exactly load balance work with and without trunking license?
Also you mentioned smart zoning before. Is there any smart zoning analog in brocade san switches?
According to Brocade documentation The trunking feature optimizes the use of bandwidth by allowing a group of inter-switch links (ISLs) to merge into a single logical link....
In practice, the main benefit of trunking is that, it appears a single logical ISL, and this simplifies the routing tables inside the fabric, and most important, when there is a failure/activation of one of the ISLs, no new calculations need to be performed, and thus the traffic disruption is minimal. In the same situation, without trunking, there is a disruption until the routes are re-calculated.
When it comes to load balancing (and the use of bandwith) between switchs, it depends on the Routing policy configured on the switch. There are mainly 2 routing policies:
Initially, when only port-based routing was available, if you had ,e.g 3 ISLs, you could have one of them heavily used whilst the other two were not used at all. In that case, trunking was very beneficial as it overtook that potential congestion situation by creating a 3-isl trunk. But since exchange-based routing was released, this situation disappeared and traffic is evenly balanced among all the ISLs. So, as far as load balance is concerned, trunking does not offer a big improvement.
If you meant the difference in load balancing withing the ISLs that form a trunk, with and without trunking licences, here there is indeed a significant difference:
Hope it answers your query.