Tag Archives: fabrics

Appalling state of Storage Networks

In the IT world a panic is most often related to a operating systems kernel to run out of resources or some unknown state where it cannot recover and stops. Depending on the configuration it might dump its memory contents to a file or a remote system. This allows developers to check this file and look for the reason why it happened.

A fibre-channel switch running Linux as OS is no different but the consequences can be far more severe.

Continue reading

Brocade MAPS – Improvement in usability, reduction in functionality

(This post is mostly obsolete to to the many improvements in FSO 7.3, 7.4 and beyond. I would seriously urge you to consider using MAPS. See here)

With FOS 7.2.0 Brocade introduced MAPS (no not the google version). It’s a new functionality that is intended to replace and improve the usability of Fabric Watch. As I wrote earlier here Fabric Watch has always been one of the best pieces of functionality in FOS and I’ve used it ever since they introduced it al the way back in FOS 3.x or 4.x I think it was (Yes I’m that old). FW enables you to create thresholds on numerous elements in a switch or fabric. This goes from port-errors to environmental problems like elevated temperature and other hardware problems. In addition individual actions can be configured like sending out emails, snmp traps or yet even better, disable ports in case it can have or already has significant ramifications and follow-up issues in a fabric.

The biggest problem with FW always has been the sheer amount of options, menu items and CLI parameters which caused it a to be a challenge to configure it to such an extend it became useful. It is like using VI (the text editor, not the company) for the first time, you’d rather have a root canal and endoscopy at the same time but as soon as you have the hang of it you discover the sheer power of this tool and the amount of proactive management, alerts and other options will make you SAN almost bullet proof (I’m not saying monkey-proof :-)). This is also the reason that FW is either not used or configured with incorrect parameters so that it will spit out too many or too few notifications. Once again I would like to stress the importance of this great tool and the ROI will certainly double both in time and money.

So then why MAPS. Remember that Brocade is also fairly active in the networking side of the fence with the acquisition of Foundry back in 2008 and more recently Vyatta to obtain a software based networking virtualization stack. With the introduction of their FabricVision roadmap you can see that overall management needs to be synchronised and consolidated. Having 4 different hardware and software platforms (SAN, Ethernet, VCS/Converged and virtual) means this is a fairly daunting task. Brocade Network Advisor has become the management framework to handle all this albeit it is still a work in progress.

MAPS simplifies the overall management of the RAS features in FOS to more align with the capabilities across these platforms. Secondly, the number of support cases related to physical issues has increased significantly ever since the FC speeds and feeds went to 8G and 16G. 8G and 16G did not only require an update on switches and HBA’s but also the requirements on cable quality changed. OM2 is no longer sufficient on these speeds. OM3 and OM4 is required for the respective connection speeds from end-to-end including patch-panels, connectors etc. Since this physical aspect of many infrastructures is not updated the increase in problems observed are almost linear proportional to the degraded quality of the physical cable plant. I’ve seen many examples whereby an 8G port was unable to connect and just by reducing the speed back to 4G it did not observe any issues. MAPS cannot help you with re-cabling your plant but it can help stay on top of issues that might surface.

What I don’t like about MAPS is that is has significantly reduced the granularity of elements, objects and values you can configure. This might not suit every environment so conflicts of interest might become a problem. Also some settings may be converted from FW but you can’t change it. This is especially annoying if you made an incorrect configuration, converted to MAPS and all of a sudden you get hit by a gazillion alerts which you then cannot modify. Also very annoying is the issue that you cannot configure different email notifications to different people. If you encounter a temperature problem you might want to let the operators of the data-centre know of this issue but when a port observes a protocol problem they don’t need to know. Currently your can’t change that.

I do think MAPS is currently a work in progress as previously mentioned and thus I cannot recommend to migrate to MAPS just yet. Maybe in FOS 7.3 or even 8 it has matured enough to fully replace Fabric Watch. If you have licenses for Fabric Watch I would certainly recommend investing some time in this and configure it according to your needs. The FW Admin guide is a great resource and it will certainly increase the stability of your fabric.

Cheers,
Erwin

UPDATE: Brocade has pulled FOS 7.2.0 due to the fact it introduced so many new defects that it became more pretty dangerous to even think about running this version. As usual the x.x.0 releases should be avoided.

ipSpace.net: FCoE between data centers? Forget it!

Cisco guru and long time networking expert Ivan Pepelnjak  hits the nail on its head with the below post. It is one more addition to my series of why you should stay away from FCoE. FCoE is only good for ONE thing: to stay confined in the space of the Cisco UCS platform where Cisco seems to obtain some benefits.

Today I got a question around the option for long-distance replication between enterprise arrays over a FCoE link. If there is ONE thing that I would put towards the HDS arrays is that they are virtually bulletproof with regards to data-replication and 6x6x6 across 3 data-centres replication scenarios in cascaded and multi-target topologies are not uncommon. (yes, read that again and absorb the massive scalability of such environments.)

If however you then start to cripple such environments with a greek trolley from 1000BC (ie FCoE) for getting traffic back and forth you’re very much out of luck.

Read the below from Ivan and you’ll see why.

ipSpace.net: FCoE between data centers? Forget it!: Was anyone trying to sell you the “wonderful” idea of running FCoE between Data Centers instead of FC-over-DWDM or FCIP? Sounds great … un…

He also refers to a Cisco whitepaper (a must read if you REALLLYY need to deploy FCoE in your company) which outlines the the technical restrictions from an protocol architectural point of view.

The most important parts are that the limitation is there and Cisco has no plans to solve this. Remember though I referred to Cisco in this article all the other vendors like Brocade and Juniper have the same problem. Its an Ethernet PFC restriction inherent to the PAUSE methodology.

So when taking all this into consideration you have a couple of options.

  • Accept business continuity to be less than zero unless the hurricane strikes with a 50 meter diameter. (small chance. :-))
  • Use FibreChannel with dark-fibre or DWDM/CWDM infrastructure
  • Use FCIP to overcome distances over 100KM
So far another rant of the FCoE saga which is stacking up one argument after another of why NOT to adopt it and which is getting more and more support across the industry by very respected and experienced networking people.
Cheers,
Erwin

Brocade and the "Woodstock Generation"

I encourage change especially if there are technological advances that improves functionality, reliability, availability and serviceability (or RAS in short). What I hate if these changes increase risk and require a fair chuck of organisational change even more if they amplify each other (like FCoE).

What I hate even more though is for marketing people to take ownership of an industry standard and try to re-brand it for their own purposes and this is why I’m absolutely flabbergasted about Brocades press-release in which they announce a “new” generation of the fibre-channel protocol.

When the 60’s arrived a whole new concept of how people viewed the world and the way of living changed. Freedom became a concept by which people lived and they moved away from the way their ancestors did in previous decades. They’d shed the straitjacket of the early 20th century and changed the world through various parts of life. This didn’t mean they discredited their parents or grandparents or even the generations before, neither did they perceive to be better or different in a sense they wanted to “re-brand” themselves. They didn’t need differentiation by branding, they did it by way of living.

Fibre-Channel has always been an open standard developed by many companies in the storage industry and I’ll be the last to deny that Brocade has contributed (and still does) a fair chunk of effort into the protocol. This doesn’t mean that they “own” the protocol nor does it give them the right to do anything with it as they please. It’s like claiming ownership of print when you’ve written a book.

So lets go back to their press release. In that they announced the following:

Brocade Advances Fibre Channel Innovation With New Fabric Vision Technology



Also Expands Gen 5 Fibre Channel Portfolio With Industry’s Highest-Density Fixed Port SAN Switch and Enhanced Management Software; Announces Plans for Gen 6 Fibre Channel Technology Supporting the Next-Generation Standard

and a little further-up:

Brocade Fabric Vision technology includes:

  • Policy-based tools that simplify fabric-wide threshold configuration and monitoring
  • Management tools that allow administrators to identify, monitor and analyze specific application data flows, without the need for expensive, disruptive, third-party tools
  • Monitoring tools that detect network congestion and latency in the fabric, providing visualization of bottlenecks and identifying exactly which devices and hosts are impacted
  • Customizable health and performance dashboard views, providing all critical information in one screen
  • Cable and optic diagnostic features that simplify the deployment and support of large fabrics

When I read the first line I thought that a massive stack of brocade engineers had come out of a dungeon and completely overhauled the FC protocol stack but I couldn’t be further from the truth. It were not the engineering people who came out of the dungeon but more the marketing people and they can up with very confusing terms like Gen5 and Gen6 which only represent the differences in speed technologies. Where the entire industry is used to 1G,2G,4G,8G and now 16G plus 32G, Brocade starts to re-brand these as GenX. So in a couple of years time you’ll need a cross-reference spreadsheet to map the speed to the GenX marketing terms.

As for the content of the “Fabric Vision technology” I must say that the majority of component were already available for quite a while. The only thing that is actually new is the ability to map policies onto fabrics via BNA to be able to check quickly for different kind of issues and setting which is indeed a very welcome feature but I wouldn’t call this rocket-science. You take a set of configuration options and you distribute this across one or more switches in a fabric and you report if they comply to these policies. The second bullet-point seems to be targeted at Virtual Instruments. From what I know of VI Brocade is still a long way off to be able to displace their technology. Utilities like frame-monitoring do not compete with fc-analyser kind of equipment.

The software side of BNA and VI seems to be getting closer which I do welcome. BNA is getting better and better with each release and closing the gap to tools which provide a different view of problems will certainly be useful. It also prevents the need for polling fabric-entities for the same info.

Bullet point  3 and 5 piggy back on already available features in FOS but now can be utilised to capture these in a dashboard kind of way via BNA. Bottleneck monitoring commands in addition to credit-recovery features plus D-port diagnostics to check on the health of links were already available. The BNA dashboard also provides a nifty snapshot of most utilised ports, port-errors, cpu and memory status of switches etc. This, in theory, should make my life easier but we’ll wait and see.

Don’t get me wrong, I do like Brocade. I’ve worked with their technologies since 1997 so I think I have a fairly good view of what they provide. They provide around 50% of my bread-and-butter these days (not sure if that’s a good thing to say though if you check out my job-title. :-)) but I cannot give them credit for announcing a speed-bump as a new generation of Fibre-Channel nor can I think of any reason of defining a “Vision” around features, functions and options that have been lacking for a while in their product set. I do applaud them for having it fixed though.

From my personal point of view what would be compulsory is to overhaul the FOS CLI. You can argue to take a consistent approach of using the “Cisco” like tree structure which Brocade also uses in their NOS on VDX switches but that doesn’t work for me either. Moving up and down menu trees to configure individual parts of the configuration is cumbersome. What needs to be done is to painstakingly hold on to consistent command naming and command parameters. This, in addition to the nightmare of inconsistent log-output across different FOS version,  is one of the worst parts of FOS and this should be fixed ASAP.

Cheers,
Erwin

Cisco Live 2013 – Datacenter mobility is the name of the game

Always being interested in datacenter technologies you can’ t walk around Cisco. Their reach into many aspects of the datacenter in addition to the various access paths to those datacenters is significant. From high-end switching technologies to secure VPN access to wireless they are everywhere.

The name of the game for the last couple of years was primarily convergence and it turns out they have embarked on that path full steam and they haven’ t looked back. A natural followup on this is mobility. Not from you or me running around with an iPhone but more towards entire virtual datacenters. The goal is to have VM mobility between private, hybrid and public clouds without service interruption. The ability to do this allows companies to fluently move services from their internal datacenters to the likes of Amazon, MS Azure, Rackspace and the likes but also to the less well known service providers.

From the service providers perspective the obvious suspects are in many cases the larger telco’s like Vodaphone, Verizon, Telefonica, AT&T etc. but also the entire managed services companies who own and operate datacenters fit very well into that goal. CSC, IBM and HP are some companies who fit in this space.

What you see is that networks will virtually extend from the private cloud (ie your own equipment) into the public space where it will act under your own security, operations and management policies. Of course this requires a fair chunk of work upfront to determine if these policies align with the services the public cloud provide can offer but when you have this ironed out the transition to datacenter mobility should be fairly seamless.

Obviously this doesn’t come for free and many of the features and functions requires up-to-date firmware on similar up-to-date hardware. So when your equipment is up for renewal you might want to have a serious look if this datacentre mobility aligns with your business outlook for the near future and act accordingly.

Another aspects which you have to take into account is which platform you select for being your private cloud stack. Do you use MS Windows 2012, Openstack, VMware or another one. You might feel very comfortable with VMware but if your preferred cloud provider is doing OpenStack you obviously have some decisions to make.

Besides pricing you also need to take into account product maturity and backing. If you found some very funky “cloud”  software on SourceForge which does all that you want from an internal services perspective you’ll likely end up at a dead-end when you want to take your VM’ s to a public cloud.
As an example VirtualBox comes to mind. Although it do a lot of things you want from a hypervisor, (cloning, snapshots, GUI & CLI management)  it doesn’t talk with anyone so seamless migrations, disaster recovery and extended network functionality such a vSwitches and VM mobility is out of the question.

Another hot topic is of course network fabric services. In this field you see Cisco moving FibreChannel characteristics to their Ethernet platforms. Some things we’ve raken for granted in the storage space for over 2 decades you now see dripping down into the ethernet platforms. vPC and FabricPath are good examples of that. From a competitive perspective it looks like Cisco is doing the opposite of Brocade where you see Brocade adopting Ethernet technologies into their FC platforms. The result is the the same (or at least similar). It now depends on the overlaying management stacks to find out which one will suit you best.

It would be great to see where Cisco takes this in 12 months from now and hopefully we see some great stuff which are mature enough to be deployed in production environments then.

To close I’d say: Kudos Cisco. Exciting stuff popping out of the labs. For customers who are about to renew  their datacenter equipment I’d advise to thoroughly look around and determine if, and how, you could deploy these new and exiting technologies.

Cheers,
Erwin van Londen

DISCLAIMER : Cisco paid the admittance to the event but had no influence in my view depicted above.