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.

Peer and TDZ Zoning

The most fantastic change is the concept of “Peer” and “Target Driven Zoning”.

Ever since FOS version “stoneage” with enhanced zoning capabilities the name of the game has always been to have single initiator zones. This prevented not only from inadvertently having hosts “seeing” each other on the fabric but also to reduce RSCN storms which could cause all sorts of nastiness. That being said when you have 1500 dual- or multi-pathed hosts and 40+ arrays with each around 200 target ports your zoning database is fairly bloated. (to say the least.) In addition to that you have to retain a very rigorous naming schema and administrative procedures to keep this in tip-top shape. This has been a torn in the eye of many administrators (and yes, also support-guys like me) since the amount of work involved was fairly significant. The chance or introducing errors in addition to the overall effect of zone changes with such large database accros many switches in the fabric triggered the need for expediting the introduction of “peer zoning”

Peer zoning

Peer zoning works with a new methodology which is called Principal to Peer communication. This basically means you create a zone with a single principal and only the principal is able to see and talk to peers. The principals themselves are not allowed to see/talk to other principals or peers defined in other zones. In essence what is does is that ACL are applied on peer-ports in a zone to only see the principal. The principal however obtains an ACL of all peer-member ports in that zone. Both a peer and principal can be member of multiple zones (including non-peer zones) which could then alleviate the statement above and allow them to see/talk each other. If you want/need to do that depends on requirements. From a schematic view it looks like this.

The initiators on the left and target on the right are member of the “Blue” zone in the “cloud-fabric” where the target is specified as a principal and the initiators as peers.

TDZ or Target Driven Zoning

The entire peer zoning methodology does not fall out of the sky. The initiating drive behind it all was to have the ability to remove human error from doing zone-changes and have storage devices determine which initiators are allowed to connect to it respective target ports. It also removed the not-so-smart idea of getting rid of zoning entirely  which obviously would introduce the phenomenon of RSCN storms (as sort of broadcast notification methodology when something changes in the fabric).  The concept itself however was not new. I’ve been discussing the same scenario and possible solutions (of which one was indeed TDZ which whe then called Target initiated Zoning) with DEC/Compaq/HP engineers in Colorado Springs back in 2000 to 2003 when we already saw the negative side-effects of growing fabrics and their lack of intelligence in this area. Given the fact some greedy CEO’s more or less used a chain-saw in the HP storage engineering departments the entire idea was shelved. To my great surprise and pleasure I read an article from Erik Smith at EMC who seem to have ran into the same observations and he drove the concept to a formal entry in the now FC-SW-06 and FC-GS-07 standards. (Big Applause !!) For his articles read his blog over here

Basically what it does is that you create a zone with a single principle member. As as soon you create a virtual storage port (Host Storage Domain in Hitachi terms)on an array and add your host options including the WWN to that HSD the zone in the fabric of which the array port is a principal will get updated with that WWN and the ACL’s on the respective switchports are adjusted accordingly. The array port in that case is instructing the fabric configuration server to add the WWN as a peer in that particular zone. An RSCN is sent to the initiator indicating something has change in the fabric after which is does an inquiry to the name-server of that change, sees the new port being available and will send a PLOGI/PRLI request to the array and voilà, connection is made. As you can see this really reduces the administrative overhead when managing zones. The only ‘gotcha’ now is to have storage vendors implement the technology. Start nagging your sales-reps and your vendor’s Product Managers. 🙂

FabricWatch vs. MAPS

First off FabricWatch is End-of-Life and does no longer exist in FOS 7.4. I’m in mourning :-).  As you probably know I’ve been a huge fan and serious advocate of FabricWatch. I’ve always urged every administrator to put this license on the “need-to-have” section of the RFP. It provided a wealth of information and is a tremendous tool to keep an eye on almost every aspect of the logical and physical side of the fabric. As of FOS 7.2 FabricWatch has been morphing into a new tool called MAPS (Monitor and Alerting Policy Suite). In combination with FlowVision (as successor of Advanced Performance Monitor which is also End-of-Life with this release) the new toolkit is called FabricVision. These two combined create the one of the most powerful tools I’ve ever seen in an embedded “firmware” image. I’ll write a separate post in that one.

If you have been using FabricWatch in the past and have created rules and alerts you need to migrate these to MAPS. FOS 7.4 is not able to do that so before you upgrade to 7.4 be sure to enable MAPS in FOS 7.3 to have the ruleset converted to a MAPS capable configuration. A simple

“mapsconfig –fwconvert”

will do the trick. I’ve written posts about MAPS over here and here but with FOS 7.3.1+ and FOS 7.4.x these are obsolete. Brocade has obtained a good feeling for RAS requirements and has learned a lot from what is coming back to them from the field in the form of enhancement requests as well as issues that have been affecting customers and they have been able to translate that into a well organised set of RAS features. MAPS is enabled by default under a “basic license” schema which allows you to keep track of overall switch status events. This is enabled by a default policy which cannot be changed. In addition to this there is a significant leap in rules that can be configured on numerous classes of events and objects. If you take your fabric serious I urge you to have a look at this. (I MEAN THAT !!)

Firmware updates.

Ever been in the situation where you get a new switch from spares which is loaded with FOS version “stoneage” and you need to go through 7 point releases to get it up to the latest supported level. That sucks doesn’t it. Well, not anymore. With FOS 7.4 you can use the “firmwarecleaninstall” command which totally wipes the current installed configuration and installs the version you are downloading. This clean slate also means the pre-configured OEM parameters are wiped which might conflict with settings your vendor might have instructed to Brocade to configure. Check with your vendor on this.

Some smaller but really nice enhancements.

When you have configured multiple users who have different authorisation levels on one or more virtual fabrics they can now ssh into a switch and automatically moved into the context which that user has configured its home fabric.

The portloginshow command has improved in a way it now can show the WWN that was last logged in into this port with the “–history” parameter. From a support-perspective this is especially useful as we only get a snapshot of a switch at a particular moment in time. It does not show us what actually was using a port.

Dynamic Load Sharing is also supported on the embedded platforms now. This should provide a much better performance balance on the ISL’s coming from a blade-system.

FlowVision has improved with some very handy additions which allow you to obtain and overall picture of the performance of a switch but also added the method to get info around specific flows from all datapoints in a fabric. (Obviously the hardware needs to be able to support this)

Conclusion

I would recommend to thoroughly read the release notes as well as the updated manuals that come with this release. From my view this release is one of the best feature wise. If the bugs stay away or Brocade is able to identify and fix them quickly I would certainly recommend moving to this version and use the new and updated features and functions.

Regards,

Erwin