There is already a fair chunk of functionality in FOS but, being a support-engineer, you always come up with features and functions that will improve storage fabrics.
Being on a Ficon course last week and meeting some Brocade friends I requested them to add the following to the (most likely) long RFE (Request for Enhancement) list.
For many years I’ve been working with Brocade fibre channel equipment and handled from small to very large storage networks. In these +- 18 years a lot of companies I worked for or who’s storage infrastructure I had the pleasure to work on or with have changed their view on design, operational management, performance, and adjusted their policies to incorporate high availability features to ensure optimal business usage of their most valuable asset, their data.
Unfortunately the opposite is also true. The design, implementation and poor overall state of many storage infrastructures I see on a day to day basis very often makes me gasp for air and stun me that these are still operational in a real life production environments. Infrastructures that run billions of financial transactions a day, hospitals, public transport, power-plants and telecommunications often suffer because a single fibre cable is the cause of havoc in network or storage infrastructures. The main reason these do not results in massive outages is often due to people being able to find a problem quickly and, to be honest, this is also a testimony to the flexibility and robustness of the Fibre-Channel protocol combined with rock-solid storage equipment which is able to obfuscate many of the problems that are lingering under the surface of the storage area network. The lack of day-to-day physical and operational maintenance that used to be done by very dedicated sysadmins is often outsourced to companies who do not budge outside their service contracts. These service contracts do not only put the handcuffs on the operational side of the fence but also contain a massive amount of legal restrictions which lead to significant penalties in case of service disruption. This not only puts the contracted service organisation in a straight-jacket for not being able to maintain this environment but also, often unknowingly, elevates the risk of software and hardware defects having a profound impact on the entire IT infrastructure.
This guide tries to walk you through the main configuration steps to create a resilient Brocade storage network environment without having the intent to replace current admin guides, white-papers or best-practise guidelines. This guide will describe what is mentioned in the official manuals but is too often overlooked or forgotten. The guide will be an ongoing series of posts each describing a separate topic and is listed under the Brocade -> Config Guide menu item.
Fairly often blog-posts will be updated. Keep an eye out and check back in regularly.
Fairly often blog-posts will be updated. Keep an eye out and check back in regularly.
I recently was involved in a discussion around QD settings and vendor comparisons. It almost got to a point where the QD capabilities were inherently linked to the quality and capabilities of the arrays. Total and absolute nonsense of course. Let me make one thing clear “QUEUING IS BAD“. In the general sense that is. Nobody want to wait in line nor does an application.
Whenever an application is requesting data or is writing results of a certain process it will go down the I/O-stack. In the storage world there are multiple locations where such a data portion can get queued.When looking at the specifics from a host level the queue-depth is set on two levels.
(p.s. I use the terms device, port, array interchangeably but they all refer to the device receiving commands from hosts.)
I really think I should stop with fillword discussions but here is one more. What happens even if you have set the correct fillword, have made sure all hardware is in tip-top shape and still the encoding errors fly around like a swarm of hornets. Then the problem of ISI might be more problematic.
The main issue still is that the receiving side is unable to distinguish between a 0 and 1. The so called eye-pattern is too narrow or too distorted in such a way the receiver is just seeing gibberish.
Houdini was a master in getting out of these things. Out of a swimming pool with a Straight-Jacket on I mean. This week I had an analogy to his problem. At a customer site Brocade Network Advisor (BNA) became totally unresponsive up to a point where it just stopped.
I’ve written about fillwords a lot (see here, here, and here) but I didn’t show you much about the different symptoms an incorrect fillword setting may incur.
As you’ve seen fillwords are a very nifty way of maintaining bit and word-sync on a serial transmission link when no actual frames are sent. Furthermore they also are replaceable with other primitive signals (Like R_RDY, VC_RDY etc) to utilize a very simple instruction method between two ports without interfering with actual frames. That means that fillwords are ALWAYS squeezed in between frames.
