This article can also be found in the Premium Editorial Download "Storage magazine: .NET server storage: Friendly or not?."
Download it now to read this article plus other related content.
Ok, you've finally convinced your management of the numerous benefits of implementing a storage area network (SAN) in your data center. The target application has been deployed, and application performance has skyrocketed. Now that your application is a screamer, it's generating a lot of buzz.
Now, you must ensure this application isn't exposed to any lengthy outages due to an error in the SAN configuration - failure will be high profile. That means backing up your SAN configuration. As soon as you make any changes to the first installed switch, back up the configuration and keep doing that immediately following any subsequent changes to the fabric.
Using the popular Brocade SilkWorm Fibre Channel (FC) switch as an example, your switch has a default configuration that includes the Fabric OS default values that Brocade has determined work best. All those values are a subset of the variables intuitively referred to as fabric.ops.
Preserving this information is no laughing matter. In order to add a switch to the SAN via their respective E_Ports, the fabric.ops parameters must be equal throughout the SAN. Otherwise, when you connect switches with dissimilar fabric.ops parameters, the fabric will segment and the port LED's will slowly blink with a green indication, and you'll be forced to find the offending parameters to correct the problem.
In addition to the fabric.ops variables, there are other configuration features of the switch that can be altered, and need to be recovered in the event of a failure. These include zoning, SNMP and Fabric Watch configurations. Each of those features requires specific configuration information relative to the supported product or feature, and as a result can be changed independently of one another. Of those features, only the zoning configuration is propagated to a connecting switch when joined with an existing fabric. In a hardware failure scenario, all other configuration would need to be reentered into each individual switch to establish the same SAN operating environment prior to the failure.
I'm going to go out on a limb: If you have a single application deployed onto a single switch fabric without any additional configuration or add-on licenses, there's no real reason to back up your SAN configuration. Replacing the FC switch with an identical new switch will yield the same configuration prior to failure.
However, if you have made changes to the out-of-the-box switch configuration, backing up your SAN configuration is imperative. From a zoning perspective, the changes in your SAN represent your application server's unique view of the SAN. By implementing zoning, you have established order in your SAN by provisioning specific storage devices to your application servers. To be able to reestablish that order in a recovered environment, you must have some notion of how your storage devices have been provisioned across the fabric. What's helpful here is to have a tool that gives you a topology map of your SAN. This bird's eye view of your configuration will prove helpful when redeploying your SAN subsequent to disaster.
Regardless of the change, typing cfgsave will save your changes to flash memory. But should the switch itself fail and become unusable, the switch and your configuration will need to be replaced and recovered. If the failed switch is part of a larger fabric, simply connecting the new, out-of-the-box switch to the existing fabric will only update the zoning information in the new switch's configuration, assuming the fabric.ops variables haven't been changed from their default values. However, should your SAN experience a software (e.g., Name Server Database) or human error (e.g., a configuration is mistakenly deleted), you will need to recover your SAN configuration.
|Backing up switch configurations|
Vital switch information can be sent via FTP to a centralized server, and from there backed up by normal means. The switch configurations can be uploaded manually to the server through the switch's command line interface or automatically by script.
The configdownload command is similar to the configupload command in syntax, and retrieves and installs the recovered configuration into the switch you are executing the command from. The procedure is so simple, and so necessary there's really no reason why this procedure shouldn't be implemented and documented by your SAN vendor as part of their professional service engagement. When executing either of the above commands, you can supply the IP address of the FTP server, the name of the configuration file and the username and password on the command line. Or you can simply press enter after typing the command, and you will be prompted for the same information. Additionally, you can execute an Expect script at designated times via a scheduler (such as cron) to perform the task of backing up your SAN configuration. However, you must be aware of the vulnerability of the Expect script's command file with regards to passwords and SAN security. Either way, the process of backing up your SAN configuration should be standardized across your fabric.
In the event of a disaster - where your entire fabric has been physically destroyed - having a backup of each of your switch's configuration will prove invaluable when your vendor sends you 50 brand-new replacement switches that you must deploy to live up to your SLA. Not that we want to keep reliving Sept. 11, but those of us who provide disaster recovery planning services have often warned our clients and our management about the possibility of a complete disaster. We just didn't imagine the scope of the events that shook our country on that horrible day. Nevertheless, it's important that we keep corporate America focused on the recovery efforts that took place immediately following 9/11. Hopefully, it will forever be the event we describe as the worst case scenario.
In a disaster of that magnitude, if you were managing more switches than one administrator could recover within your SLAs, having a product like Brocade's Fabric Manager could prove useful. Fabric Manager is a GUI interface that's tightly integrated into WebTools to enable the management of multiple Brocade switches from one console. One of the features of Fabric Manager is that you can choose a model switch, possibly the principle switch, to clone other switches using the model switch's configuration. This feature will save you a significant amount of time in most disaster recovery scenarios by eliminating the need for the administrator to type in each of the switches configuration parameters. If you have one, two or three switches, this particular feature of Fabric Manager may not be as important as its other offerings. However, for larger, dynamic fabrics that are continually scaling, being able to clone a new switch with an enterprise-wide switch profile will not only save you time on the initial deployment, it's also helpful during troubleshooting exercises to know that your enterprise-wide SAN configuration is being managed and is the same throughout the fabric.
There are many advantages to backing up your SAN configuration. However, the most pronounced advantage is the time and revenue saved by being proactive with the recoverability of your SAN. So whether you're responsible for one or many SAN switches, ensure your applications' recoverability by backing up your SAN configuration.
This was first published in August 2002