As I’ve written before some features in FOS 7.3 and older have been superseded by new tools such as MAPS and FlowVision. On of those is also Advanced Performance Monitor which let you set up monitoring points in the fabric to identify traffic patterns. Continue reading
Storage networks have been used for disaster recovery and business continuity purposes for as long as fibre-channel existed. The moment arrays could communicate to other arrays over either short or long distances replication software has been developed and incorporated in firmware so that data could be copied to remote sites.
It is no secret that many vendors use open source software in their products and solutions. One of the most ubiquitous is Linux which is often the base of many of these products and used as core-OS because of it’s flexibility and freely available status without the need of keeping track of licenses (to some extent) and costs.
These OSS tools have different development back-grounds and are subject to policies of the person (or people/companies) who develop it. This obviously results in the fact that defects or bugs may result in security issues especially when it involves network related applications. Recently the bugs in OpenSSL and Apache have gain much traction as some of these are fairly significant and can result in access breaches or denial of service.
The piece of spinning Fe3O4 (ie rust) is by far the slowest piece of equipment in the IO stack. Heck, they didn’t invent SSD and Flash for nothing, right. To overcome the terrible latency, involved when a host system requests a block of data, there are numerous layers of software and hardware that try to reduce the impact of physical disk related drag.
One of the most important is using cache. Whether that is CPU L2/L3 cache, DRAM cache or some hardware buffering device in the host system or even huge caches in the storage subsystems. All these can, can will, be used by numerous layers of the IO stack as each cache-hit means it prevents fetching data from a disk. (As in intro into this post you might read one I’ve written over here which explains what happens where when a IO request reaches a disk.)
To many it has always been a mystery what happens when you connect fibre-channel switches to each other and all of a sudden magic happens and you can have an host “talk” to an array or an other device on an other switch. The same mystery however applies when this doesn’t work and you see “E-port segmented, port disabled”. In later FOS codes you may see some additional cryptic reasons like “ESC mismatch” but to many this is as gibberish as particle physics.
This post explains most of the important settings on an Brocade switch port destined to become an E-port in either a standalone master or in a slave role as part of a trunk. I’ll also highlight the importance of some settings when it comes to virtual channel initialization on both short and long distance settings as well as things seen on the wire when an ISL is segmented due to a fabric configuration problem. This post also touches on C/DWDM connectivity in relation to Brocade ISL’s.
As with all good stuff there are always people and companies that try to jump on the bandwagon and make some dollars by using cheap kit and sell it as “Original” or “Compatible” or “Vendor equivalent”. Don’t fall for this trap and simply buy Original Vendor Branded & Supported equipment. One example is FiberStore.
One of the regularly used features in BNA is the ability to retain performance numbers and a history of port errors. It is then most annoying when these graphs show a flatline when you know there is a significant amount of traffic traversing these links.
As a support-guy you very often look at port counters. These do not only provide insight into the status of a port but also may give statistical information which allows you to plan and design new connectivity layouts and diagrams or give some general advice. If you look at the wrong counters though you may be in for a surprise as some may not tell you the actual truth.
I’ve written about Fabric Watch quite a lot and I have always stressed the usefulness of this licensed add-on as a feature in FOS. This post will outline the major characteristics of MAPS and why you should migrate now. As of FOS 7.2 there has been a transition from Fabric Watch to MAPS (Monitoring and Alerting Policy Suite) and over the past few FOS versions it has seen a huge improvement in overall RAS (Redundancy, Availability and Serviceability) monitoring features. As of FOS 7.4 FabricWatch is no longer incorporated in FOS and as such MAPS is the only option you have if you want to use it. MAPS is one section of a two part suite called Fabric Vision together with its performance companion “Flow-vision”. The MAPS part can interact with flow-vision based on criteria you specify and monitor/alert on performance related events.
So now and then you run into this issue where, no matter which configuration you try, a switch port always shows:
86 10 6 3a5600 id N8 Online FC L-Port 1 public
Even though all settings seem to be OK, fillwords are correct, HBA or array settings are the same as others, no port-errors are seen from a switch perspective but this port will not come up as an F-port.