...
As an improved alternative, switch and fabric related information can now be collected from the switches directly using REST API.
This feature requires Fabric OS 8.2.1 or higher (see Supported Brocade systems).
Refined Object model
Brocade SAN REST Model has been refined to reflect the Brocade API model:
Information gathering
While BNA was a single point of entry for BVQ and provided us the data for all switches and fabrics managed by the BNA, it is now necessary to create one scanner instance for each fabric.
For switches having virtual fabrics enabled, a scanner instance for each virtual fabric id is required.
It is recommended to use the fabric principal as the main switch in the scanner configuration. Other switches in the same fabric are discovered automatically by the scanner configuration.
Switches in access gateway mode are not part of the fabric, and hence, have to be added to the configuration manually.
| Expand | ||
|---|---|---|
| ||
|
Additional information:
- See Supported Brocade & Cisco SAN systems for more information about supported HW/SW.
- See Scanner for more Information about BVQ Scanner configuration.
- See Brocade SAN Switch preparation for additional Switch preparation tasks.
- See /wiki/spaces/~557058f85a2b71be2d496e8e4575a825a92089/pages/13831307 for more details about scanned information.
Additional use cases
The legacy SMI/S interface restricted the available information, that new REST interface now shows.
Once the scanners are collecting data, all topology and performance information known from the previous Brocade module plus a bunch of new attributes and metrics can be explored in BVQ - be it the Expert GUI for a deep dive, Grafana dashboards for a nice graphical overview, or the predefined alert rules which are visualized in the Systems Health map to quickly see the state and health of the SAN configuration.
...