San data collection – Brocade Network Advisor SAN + IP User Manual v12.3.0 User Manual
Page 234
164
Brocade Network Advisor SAN + IP User Manual
53-1003155-01
SAN data collection
5
If your Management application server fails and you must recover information to a new server,
restore the data (Refer to
on page 163 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
events is the lazy polling interval plus the short tick interval. To increase polling efficiency, you can
configure both the short tick interval (Check for state change every option) and the lazy polling
interval (If no state change, poll switch every option) on the Options dialog box. For step-by-step
instructions, refer to
There are two types of collectors, fabric-level collectors and switch-level collectors. Fabric-level
collectors gather fabric-level information. The Management application collects fabric-level data
from the seed switch, for example, the NameServerCollector gathers data about all end devices
present in the fabric.
The Management application uses the following Fabric-level collectors:
•
DeviceFDMICollector – Collects FDMI-related information for end devices in the fabric.
•
NameServerInfoCollector – Collects data about end devices in the fabric.
•
ActiveZoneInfoCollector – Collects the active zone configuration in the fabric.
•
ZoneInfoCollector – Collects the defined zone configuration in the fabric.