Click here for a list of topics on Using SAN Health
Review the videos and sample report at http://www.brocade.com/sanhealth. Here you’ll find all the instructions necessary to run it in your environment. As a guideline, each report should contain one SAN. As a reminder, a SAN is composed of one or more related fabrics and devices (for example, a dual-fabric SAN). A fabric consists of one or more connected switches.
The report might also contain multiple fabrics or several individual switches that are used for a single business purpose. While many users of SAN Health run the capture tool on each fabric in a SAN simultaneously, it might make sense to run SAN Health sequentially on each fabric in the SAN, one at a time (for example, Fabric A first and then Fabric B). This is perfectly acceptable and in fact is recommended.
You should think carefully about the names you choose, because they are used extensively in the report and are the basis of section headings. Using logical names will help produce a report that is easier to read. You can base the names on the physical location of the switches, the logical location of the switches, or even the use of the switches (switches attached to the backup portion of the SAN, for instance).
SAN Health has been tested capturing performance data for a maximum of 48 hours, the maximum time currently supported. Some users have simply scheduled another SAN Health workstation to continue after the initial 48-hour period has expired. This is perfectly acceptable, but note that a second processing event must take place and a second report and Visio diagram will be generated. For long term performance capture we suggest that you investigate the MTRG-based utilities on My Brocade (http://my.brocade.com). There is a 22 hour option to ensure that the performance capture stays under 24 hours as some users have requested this option.
The performance data capture intervals are automatically calculated, and depend on the capture duration you choose. 500-to-700 sample brackets enable the best format for the resulting Excel graph. The sample interval is calculated to be the nearest logical interval for the sample period that fits into that 500-to-700 sample bracket. As an example, for a performance data capture time above four hours but less than eight hours, the sample period will be 60 seconds. A capture time of between eight and 12 hours will use a 90-second sample interval.
If you are running SAN Health from a Windows terminal server and you leave a capture session running for a long period of time, don’t forget to extend the Windows terminal user session time out. Otherwise, the user session on the terminal server will end and the captured data will be lost. SAN Health does not save incremental capture data: All data is saved only on completion of the overall process.
Switch passwords are saved locally on the end user's computer in the Audit Data Set that you can choose to save if you wish to re-run the same audit again. When the passwords are saved in the audit set, they are triple encrypted using three different algorithms which the security industry refers to as cryptographically strong, and additionally a complex matrix of rolling keys is applied. It is important to note that the switch passwords are NOT included in the .BSH file and are NOT sent to the report generators.
No, this is normal and expected. For example, when you issue the command slotshow against a non chassis-based system, newer switches respond with "command not available on this platform," whereas older switches respond with "command unknown." In addition, the older the firmware level is, the fewer commands that respond with values. For example, when you run SAN Health against a SilkWorm 1000 running Fabric OS version 1.6, at least half of the commands will generate replies of "command unknown." This will not negatively affect your report.
Unfortunately, the diagnostic data that can be obtained from these switches via the telnet or SSH interface does not contain reliable performance information and this information cannot be captured.
If you open the .BSH file (using any text editor), the details are at the top of the page. You can attach the .BSH file to an e-mail message and send it to SHUpload@brocade.com, or you can upload it via the Web tohttps://my.brocade.com/upload/ReportGeneration.jsp.
If you are running an audit against a large number of switches on a low-power workstation, in order to ensure switch session integrity, SAN Health sets the screen refresh to the lowest priority. The switch telnet sessions have not stopped, there are simply not enough spare CPU cycles to repaint the graphics in the SAN Health application. This will not negatively affect your audit. If you are interested in seeing the screen refresh in real-time, try running SAN Health again from a more powerful workstation.
If a telnet session does stop for any reason, SAN Health will time it out after 90 seconds of activity, displaying an orange warning banner as the session is timed out. SAN Health will then close the telnet socket and clean up the memory resources that were in use.
SAN Health will automatically create hyperlinks for the devices on the Visio diagram. For switches, it will create a Telnet and WebTools hyperlink. Additionally, any optional hyperlinks that you request when running SAN Health will be created. Optional hyperlinks can be specified in the 4th column of the CSV file, or generic hyperlinks can be created to the device/switch WWN dependant on the option setting in SAN Health > Options > Diagram Format.
Custom hyperlinks can be created for almost any task. Examples include opening a data file, launching a java LUN management utility, telnetting to a UNIX box, running a script or program, etc.
Note that if a hyperlink refers to a file resource, this file or a pointer to it must exist in the same directory as the Visio diagram or Excel file that contains the hyperlink.
When the file is complete, SAN Health double encrypts and compresses the file. The first encryption pass uses 256-bit AES. The second encryption pass (after the compression) is Triple DES.
There is a known uncommon defect in FOS 6.2.2d specific to the 4024 that can cause an issue with the management server daemon when running certain CLI commands under specific scenarios.
As SAN Health is designed to be non-intrusive and to avoid risk, we simply don’t allow it to run against that box on that firmware level. We would recommend that you upgrade the firmware. This is the only way to get SAN Health to audit this switch.