Published: 12 Sep 2002
Users of Brocade switches should consider Fabric Manager for their admin staffs. The package has a number of features that will increase staff productivity
Hardware costs may have dropped dramatically, but the cost of owning storage hasn't dropped commensurately. If you haven't realized that every dollar you spend on hardware triggers as much as another $6 in actual ownership costs - largely for staff - let me be the first to tell you.
Once you've paid for the hardware, you have to pay people to provision, monitor and manage it. How efficiently you do that can have a big impact on your total cost of ownership. For that reason, I recently evaluated Fabric Manager, the management application shipped with Brocade switches. Fabric Manager is a Java-based GUI application that provides a portal into a maximum of eight fabrics and up to 200 switches.
Fabric Manager combines the functions in Brocade's Web Tools with some additional organizational and management features. As a result, you must have an optional Web Tools license installed in the switch that you intend to manage via Fabric Manager. And although the Secure Fabric OS license isn't required to operate Fabric Manager, it's definitely beneficial to have Secure Fabric OS' features available to Fabric Manager.
Brocade's Secure Fabric OS gives Fabric Manager access to security policies that are defined and enforced by your Enterprise Storage Policy. For example, in a lights-out operation there may be a policy restricting access to your storage area network (SAN) infrastructure via a serial connection. Fabric Manager allows you to assign this policy to one or more switches individually, or to a logical group. In a SAN with a large number of switches, having an aggregate console to establish and enforce these policies will help ensure your storage policies are being implemented, and should lower your overall management costs as well.
Logical groups simplify redundant storage
By assigning all the switches in each fabric to their own logical group, you can provide administrators with a quick way to see which switches belong to which fabric.
In addition to being an aggregate console for Web Tools, Fabric Manager offers other management functions such as the logical grouping of SAN switches, the creation of reboot sequence groups, as well as the backup and recovery of a baseline switch configuration and ISL Monitoring.
Using logical groups, the administrator can establish a view of the SAN that makes sense to them based on the managed applications' needs and deployment. For example, an administrator may be managing storage for a Microsoft Exchange Server with two HBAs connected to two separate fabrics (see "Logical groups simplify managing redundant storage" sidebar). In this scenario, having switches in logical groups associated with different channels supporting access to mirrored data will give the administrator the ability to manage the switches supporting their respective channels independently. This makes such tasks as firmware upgrades, rebooting and monitoring more visual to the administrator. And experience has taught us that it's far less complicated for humans to comprehend and manage a network that can be visualized, instead of a network that's seen as individual devices connected via CAT-5 or fiber cabling.
Reboot sequence groups can be created to give the storage administrator the ability to reboot a group of selected switches at a chosen time. This not only eases the administrative burden of logging into each switch to perform a reboot, it also could lessen application downtime during a troubleshooting exercise by allowing the administrator to reset a channel composed of some number of switches defined in a logical group.
There was one feature that I found particularly interesting and useful. Recently, I've been preparing corporations for site recoveries such as the ones that took place immediately after the events of Sept. 11. Fabric Manager gives you the ability to create a baseline snapshot of a source switch's configuration, and then clone that switch's configuration to other switches As you might expect, having the ability to recover the switch configuration of 100 SAN switches in a short period of time is an absolute benefit to your applications and its users with regard to your SLAs.
In a scenario such as this, you still must contact Brocade for new licenses because the licenses are dependent on the last three bytes of the switch's world-wide name (WWN). And at this point, you would be working with 100 new switches that have WWNs that are different from the ones destroyed in the disaster. However, Fabric Manager gives you the ability to manage your switch licenses centrally by loading switch licenses from a designated switch. This too could be a timesaver when deploying a large number of switches.
Backup and recovery
Having the ability to utilize Fabric Manager in this way largely depends on the successful backup and recovery of the server or workstation running Fabric Manager, unless you have the advantage of having that workstation located and accessible at your off-site location before the disaster happened. Yet, having this functionality available to you doesn't preclude you from taking regular backups using the ConfigUpload command. Cloning switches from the saved baseline configuration only recovers the newly deployed switch with an enterprise-wide base configuration. In most cases, that will be fine. However, should you have hardware or software operating in your SAN that requires some special tweaking in the connecting switch, then these special configuration changes will need to be applied to the individual switch after the baseline configuration has been applied. This can be done using the ConfigDownload command.
Although the MTBF numbers for the switch ASICs and the connecting fiber optic cables are pretty high, ISLs do and will fail. Therefore, Fabric Manager's ability to stamp or take a picture of your current ISL design and then monitor any changes should be an additional value to your storage management arsenal. However, in order to use this particular functionality of Fabric Manager, you must upgrade your switches to Fabric OS v2.6 and higher. Furthermore, this feature is only available if you enable ISL Checking within Fabric Manager's configuration. You'll find this option in the Action pull-down menu under ISL.
After enabling ISL Checking, any changes to the ISL configuration will be noted in the Events page. Should you require a reconfiguration of your ISL design, either adding, removing or replacing an ISL, you can take another picture of, or restamp the new ISL configuration by accessing the Action/ISL pull-down menus. This is an important step because if you desire to rebuild your SAN from your Fabric Manager's perspective, it would be nice to have the latest topology picture stored in the persistent files being updated by Fabric Manager.
For the most part, my exercise of Fabric Manager's features met my expectations. However, there were a few cosmetic concerns regarding its status reporting functionality. For instance, the fabric status didn't get reset within the GUI when the switch was powered down and then powered back up. Also, Fabric Manager offers a feature called Fabric Merge, which basically goes through the steps of merging two of its managed fabrics by simulating what would happen if the fabrics were connected by ISLs. In a couple of instances where I expected the simulated merge to fail, no failure was reported. After contacting Brocade support, I was informed that upgrading to Fabric Manager 3.02 corrects these issues.
Having a tool like Brocade's Fabric Manager to aggregate the management of your switches into a single console is a must for organizations with a large number of switches and looking to lower administrative costs. SAN management will continue to be the focal point of ISVs in the storage space. After all, it's an area where a ROI analysis can clearly show the benefits of having these tools available to your administrators.