As a Scot, I have a natural predisposition – almost a gene – for money saving initiatives!  As I’ve been researchin g new initiatives in my work for Cisco Services over the past few months, I’ve become aware of – for the first time I am ashamed to say in some cases – some huge sinks of your cash in today’s data centers.  In this blog, over 2 parts, I’ll share these with you, with the aim of encouraging you to invest in these money saving activities, with the aim of freeing up investment funds to subsequently modernize your data center, transform your end user experience and improve your asset utilization financial metrics.  In fact, you could create your own “Save to Invest” program by following the 5 tips below.  And while you’re reading this, put on your headphones, turn up the volume, and listen to my “theme tune” for this article, “Money!” This week I’ll discuss …. (1) Identify, Turn Off and Remove Idle Servers (2) Identify Un-used Enterprise Software Applications: Reduce Your Software Costs (3) Get Rid of Dead Weight – Execute a Server Refresh (1) Identify, Turn Off and Remove Idle Servers The presence of idle servers (research suggests 20-30% of all servers in a given data center) in your IT estate was a topic for 2 of my earlier blogs (see part 1 and part 2).  It’s a bigger and more pervasive problem than you think.  I won’t repeat my earlier blogs, however suffice to say I’d recommend you start by systematically identifying (using advanced discovery tools) and removing idle, unused servers (virtual as well as physical) from your data center, as the first step in your “Save to Invest” program. (2) Identify Un-used Enterprise Software Applications: Reduce Your Software Costs Closely related to (1) above, with an appropriate deep discovery of your application estate, you will almost certainly be able to find software applications that were installed, used for a short project ….. and then forgotten about – software that is now installed but un-used.  Let’s be honest: we’re all too busy with daily fire-fighting and the occasional longer term project work to deal with such tidy-up actions.  In the meantime, you continue to pay software licensing and/or technical support fees.  This issue is compounded in these days of easy-to-spin-up virtual machines.  Now, if you have a vendor Unlimited License Agreement (ULA), this may not be an immediate issue.  However, you may regret not paying attention to idle software if you have to face a vendor audit (as I will discuss in part 2) – it could be your leverage in a ULA negotiation. (3) Get Rid of Dead Weight – Execute a Server Refresh It may sound counter intuitive to recommend that, as part of a “Save to Invest” program, you perform a server refresh – that is, replace some older servers with newer models. However, if you look at the older servers running in your data centers, running perhaps soon to be unsupported operating system versions, you are likely to find them more susceptible to security scares, with low levels of virtualization, as well as consuming more space and power than their modern equivalents.  By modernizing your server estate, you may not only improve end user experience and reduce power costs, you may indeed (by freeing up space) extend the life of your data center. I’ll add a few more cost saving ideas in part 2.  Before ending, let me say a few words on making such a “Save to Invest” program a reality. Key to such an exercise is a deep discovery to identify the servers of a given age and size that should consider as refresh candidates.  And of course, as you migrate to the new servers, you can take advantage of increased virtualization and increased compute density in order to free up rack space and power.  This is where Cisco Services can help, together with our discovery partner iQuate and our Application Services portfolio. ... View more

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. 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! ... View more

One of the aspects I really enjoy about my job is that I get to learn from some of the world’s top network and data center design engineers, and I get to hear about technology adoption challenges across the world. If there is a complex network or data center design being worked by our customers, if our customers are under time pressure, or if our customers are facing key business or technical challenges, Cisco Services’ consultants are often called in to help.  Globally then, they experience first hand the challenges of deploying advanced technologies.  In this blog, in the same spirit as my OpenStack Deployment Challenges blog, I’d like to share their experiences on some of the most common challenges and misconceptions faced by our customers when building Storage Area Networks (SAN).  I’ll publish this in 2 parts – so look out for the concluding part next week. Before continuing, I’d like to thank two of our SAN expert consultants, Barbara Ledda and Wolfgang Lang, for sharing their experiences and challenges. First, before I start, a caveat: please don’t take this as the definitive list of SAN design challenges!  That said, they are some of our “favorite” issues that we see with customers.  Let us know if you have a favorite to add to this list, please add a comment in the box below or ping me on Twitter (details below).  Now on to the list ….. #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! Designing a highly resilient SAN network design with built-in redundant paths is a key aim of our consulting team.   On the server estate, such design requires that multi-pathing software [e.g. EMC PowerPath, Microsoft I/O (MPIO)] is installed and operational on each server.  Such software creates redundant paths to the storage environment (among other capabilities). However our experience shows that in many cases, the customer doesn’t have this installed or in cases even licensed.  In other cases they’ve never tested this capability on their servers.  Testing is important – I doubt if anyone is immune to making configuration mistakes when setting up a networking or compute device. We’ve come across this in real life: the first time when failover was required, the customer experienced an outage in the SAN network as a result of mis-configurations in their multipath software. Therefore Lesson #1 is to make sure your server team are engaged in your SAN design process, and that they have this important software installed and tested, in a position to be able to exploit your advanced SAN design. #2 Tendency to significantly over-estimate utilization on the SAN network.  You may think that as a hardware vendor, we like customers to over-specify their network.  This is not the case – we are always looking for the most cost-effective solution for our customers.  We have, in practice, noticed that customers have a tendency to significantly over-estimate the utilization on their SAN network.  For example, it’s not uncommon for us to review customer designs were they have specified 16 GB/s links when they will use a maximum of 1 Gbp/s! As you will be aware, Ethernet LAN network are able to deal with packet loss, and they rely on the upper layer protocols to do so. This is not the same for Fibre Channel networks which require the traffic flows to be lossless in order to avoid I/O disruption and loss to connectivity to storage. Consequently, to avoid any risk of congestion, SAN designers tend to overprovision their SAN. However over-provisioning of the SAN links is not always the solution, because in many cases, the root cause of the congestion is that some receivers of the traffic flows are “slow drain devices” – that is, they are “slow” in processing the packets.  You can read more on this in the whitepaper here. Hence while over-provisioning is a necessary design technique for SAN, the perception we find is that typically customers think they need 5-10x over provisioning; our consultants’ experience indicates that typically you need only double. Lesson #2: Get expert help to accurately assess your SAN capacity needs. That, then, concludes my part 1. In the meantime, I’d like to hear what are your top SAN design challenges?  Let me know via the comments box below or contact me on Twitter and we can discuss with our Cisco Services’ SAN design experts! And finally, look out for my part 2. ... View more