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.
Normally I don’t send out these notices as I think its the responsibility of the storage administrator and vendor sales-teams to keep up-to-date with product life-cycles, however in this case I make an exception. The Brocade 48000 has been a very reliable workhorse since 2006 where it succeeded the, then seemingly overpriced, 12000 and 24000 directors. In contradiction to its predecessors, the 48K gained massive popularity mainly due to the attractive price-point and longevity of life-span in addition to a fairly matured and well featured (for that time) FOS operating system.It was also the last system featuring the well known SilkWorm logo. (Which I like more than the B-wing symbol. :-))
Whenever you see a leap in a minor version there is a bucket-load of new functions and features in software and FOS 7.4.0 is no exception. Besides the usual bugfixes and snippet enhancements there are a few that I would like to highlight here.
Brocade isn’t always very forthcoming about what they are working on. Obviously a fair chunk of development and engineering efforts are spent on cloud integration and enablement of their software and hardware stack into this computing methodology. Acquisitions like Foundry, Vyatta and now Connectem show that the horizon has broadened the views of Brocade. To keep up with the ever increasing demands for network features and functions it makes sense to review the current product lines they have and when you read between the lines you may be able to spot some interesting observations.
Ever since the dawn of time the storage administrators have been indoctrinated with redundancy. You have to have everything at least twice in order to maintain uptime and be able to achieve this to a level of around 99,999%. This is true in many occasions however there are exceptions when even dual fabrics (ie physically separated) share components like hosts, arrays or tapes.. If a physical issue in one fabric is impacting that shared component the performance and host IO may even impact totally unrelated equipment on another fabric and spin out of control.
Huh, what did they come up with now??? A new way of zoning? FCoE zones? Is this the opposite of target initiated zoning??
Well, no, actually nothing of such sort. Brocade abandoned FA and QL zoning over a decade ago but so very rarely I run into it. From a FOS configuration perspective these zone still operate but no management application is able to handle it any more.
So every now and then I get the question if it is possible to access the BNA database in order to get info which then can be used to fill an excel spreadsheet for reference purposes. The though process is that often BNA/Storage administrators don’t want server admins to fool around in BNA and accidentally make changes or configuration mistakes but in the same time be able to provide insight in the SAN from a install base and configuration perspective. Although there is nothing wrong with the intent of that thought the method is however very questionable.
You might have heard about it, maybe not, but it can become a problem if it stings you: “A stuck VC” . So first of all what is it? Well, basically it is a virtual channel on an E-port or back-end port that has depleted the number of credits on one or more Virtual Channels of that port.