Last week, here, I started my 2 part blog on some of the top SAN design and deployment challenges we see. As I mentioned, I put this together with help from my SAN expert colleagues, Barbara Ledda and Wolfgang Lang. We are all part of the Cisco Services professional services team, where we experience first-hand the challenges of adopting new technologies including SAN.
Last week, we discussed the following challenges:
#1 Don’t assume that your server multi-pathing software is installed or working, or even licensed, or installed but never used/tested by your server team!
#2 Tendency to significantly over-estimate utilization on the SAN network.
Lets’ now discuss our challenges #3 – #5, which will discuss interoperability, expertise and architectural details respectively. Architectural details as it turns out is a key concern of some of you reading Part 1 of this blog – a few questions came in and you can view the discussion here (and thanks to my colleagues Venkat Kirishnamurthyi and Jing Luo for contributing to this discussion). With this in mind, you may find the Cisco MDS architecture discussion video here also useful.
#3 Interoperability doesn’t really exist!
OK, if you are working in a multi-vendor SAN environment, you probably know this already. Networks rely on standards that multiple vendors adhere to. Customers also demand innovation in areas that the standard either doesn’t address or hasn’t yet caught up with. This is the “catch 22” of advanced protocol design.
Some vendors – we won’t name them – have rejected interoperability modes of operation, in favour of adding innovative yet proprietary features. While we in Cisco have added such features, we always try to design with the “minimum common denominator” in mind i.e. we have retained inter-operability support. In this way, you can still opt for inter-operability across vendors (albeit at the expense of losing some advanced Cisco-only features, but at least with Cisco, you always have the option to interoperate).
Lesson #3: Question your SAN vendors aggressively on their support for inter-operability. Or choose Cisco – where you have a choice of inter-operability or advanced feature support!
#4 Lack of Fibre Channel protocol knowledge in IT departments
Unfortunately, over the past 5-10 years, IT and in particular SAN design and operations teams, have been squeezed as IT budgets have been reduced. Consequently, our consultants in the field have noticed a significant decline in broad availability of fibre-channel SAN design experts across our customer base. This has proven a challenge to more than a few companies who have decided to extend or modernize their SAN.
Lesson #4 then is to:
- Look after your SAN engineers 🙂 – you may find your competitors luring them away, or
- Get some expert help in! Cisco Services are here to help with SAN architectural and design expertise, with SAN Health checks (which leverage Cisco-designed automated tools that you can’t buy off-the-shelf), and SAN optimization
#5 Understand your hardware capabilities really well
Lesson #5 is to ensure that you and/or your design team understand in detail the limitations of your SAN hardware. Here are some examples of the issues that can occur if you don’t.
As I’ve discussed above, designing multiple redundant traffic paths is a key pillar of best practice SAN design. Therefore you must consider what will happen if, for example, a SAN line card fails, bringing a redundant path into live network operation. Will that second line card (and associated switch) be able to cope with the traffic demand? Don’t assume it will, investigate your hardware capabilities in detail.
It’s important to fully analyse and understand the architectural benefits (or otherwise!) of your SAN switches. Look – in particular – for architectural issues that will cause, for example, performance issues under heavy load. It’s not uncommon with some vendor’s switches to find over-loaded ASICs causing SAN performance issues. There is a good discussion in the comments on my Part 1 blog last week – thanks for these questions guys!
Cisco MDS SAN switches have a non-blocking, non-oversubscribed architecture. Some of our competitors do not! If you choose a switch architecture that is NOT non-blocking, non-over-subscribed, they you can expect performance issues e.g. significant jitter and latency in your SAN network. You may find that your switch internally runs out of internal buffer space, causing a long delay in sending frames. In practice, such issues are very hard to diagnose. (For more information, there is a good discussion on YouTube on the Cisco MDS “Crossbar” architecture and its advantages, which you may be interested in).
Wrapping Up
Concluding my discussion of SAN design challenges, I hope you’ve found this useful. What are your top SAN design challenges? Do you agree (or disagree) on our choices of key issues above? What have you experienced? Let me know via the comments box below or contact me on Twitter and we can discuss with our Cisco Services’ SAN design experts!
Thanks Stephen this is a very informative blog