Consistency is one of the most important things in a computing environment. There are abundant examples where configuration inconsistencies have led to disastrous events leading up to dropped databases, setting up disk-mirrors in the wrong direction (ie overwriting a perfectly good partition with an empty one), operational mistakes due to wrong or unclear naming conventions and you name them. Anywhere where people work mistakes will be made so in order to try and prevent these kind of mistakes strict standards in operations needs to be followed. In the majority of businesses around the world some sort of framework for processes and changes is followed in the likes of ITIL or any of the alternatives.
Category Archives: Brocade
3 – Reference architecture
In this series of post I will start with a simplified SAN architecture based upon a dual-fabric edge-core-edge design. (Remember this might not be a good design as I described here but for the purpose of this guide it will suffice.) As we go along with other topics we’ll extend it as needed. The top switch is SW01, the core switch is SW02 and the bottom switch is SW03. This is valid for both fabrics.
2 – Creating the management landscape
The first thing to think of when creating a Brocade storage network has nothing to do with a switch configuration at all. Its about the surrounding management landscape. There are numerous management software options available from a multitude of vendors including Brocade with Network Advisor. If you have purchased BNA then congratulations, you have a solid toolkit in your hands to take care of nearly everything you need to manage, maintain and troubleshoot the SAN. Despite this there are more things to take into account.
RFE for Brocade FOS
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.
Queue-depth
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.)
Signal quality and link stability
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.
Brocade Network Advisor – Java memory size.
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.
Fillwords IDLE vs ARBff (one last time)
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.
Speed mismatch is the death-trap for shared storage
I’ve been focusing on the implications of physical issues a lot in my posts over the last ~2 years. What I haven’t touched on is logical performance boundaries which also cause extreme grief in many storage infrastructures which lead to performance problems, IO errors, data-corruption and other nasty stuff you do not want to see in your storage network.
Performance expectations with ISL compression
So this week I had an interesting case. As you know the Hitachi arrays have a replication functionality called HUR (Hitachi Universal Replicator) which is an advanced a-synchronous replication solution offered for Mainframe and OpenSystems environments. HUR does not use a primary to secondary push method but rather the target system is issuing reads to the primary array after which this one sends the required data. This optimizes the traffic pattern by using batches of data. From a connectivity perspective you will mostly see full 2K FC frames which means on long distance connections (30KM to 100KM) you can very effectively keep a fairly low number of buffer-credits on both sides whilst still maintain optimum link utilization.