Restoring data to a new server, San data collection – Brocade Network Advisor SAN User Manual v12.3.0 User Manual

Page 134

Advertising
background image

82

Brocade Network Advisor SAN User Manual

53-1003154-01

SAN data collection

4

6. Click Restore.

Upon completion, a message displays the status of the restore operation. Click OK to close the
message and the Server Management Console. For the restored data to take effect, re-launch
the Configuration Wizard using the instructions in

“Launching the Configuration Wizard”

on

page 6.

Restoring data to a new server

NOTE

The restore data files must use the exact directory structure as the backup directory structure (refer
to

“Backup directory structure overview”

on page 76).

If your Management application server fails and you must recover information to a new server,
restore the data (Refer to

“Restoring data”

on page 81 for complete instructions).

SAN data collection

The Management application uses collectors to gather data from switches, persist the switches in
the database, and to publish the collected data to the client. Each collector polls data for one
feature area using HTTP or HTTPS (web pages or CAL calls) to communicate with the switch. For a
given switch, only one collector runs at a time. When you first discover a switch, all collectors
associated with that switch type run to gather data on the switch. After that, the Management
application schedules each collector to run independently. Since this is a fairly repetitive task, the
Management application has a collection framework which schedules these collectors to run
periodically (using lazy polling).

When a data collector fails, the Management application automatically retries the collection after
the short tick interval. However, there are two exceptions to this retry rule:

If collection failure is due to an ACL rule blocking access to the switch, the Management
application retries collection after the lazy polling interval (not the short tick interval).

If collection failure is due to incorrect switch credentials in the Management application, the
Management application retries collection three times after which all communication with the
switch is stopped to prevent lock out of the Fabric OS user due to too many failed login
attempts.

In addition to the automatic collection retry, you can configure adaptive asset collection to trigger
specific collectors to run when a particular event occurs. For example, when the Management
application receives an SNMP trap that a port has been disabled, the Management application
triggers the TopologyCollector (which collects ISL information) and the SwitchAssetCollector to
make sure that the client reflects the changes due to the port going down. Adaptive asset
collection occurs within the short tick interval.

The Management application uses the short tick interval to ping the switch for a periodic
reachability check. If the reachability check succeeds, then the Management application runs
pending collectors triggered by an event. When no SNMP traps or syslog events occur, the
Management application uses the lazy polling interval to schedule collection of configuration and
status changes. The lazy polling interval process schedules any pending collectors for the next
short tick. Therefore, the interval between collections when there are no SNMP traps or syslog

Advertising