Availability framework
General information
An availability framework computes periodic outage time and outage counts from state change records contained in the auxiliary database data dictionary. Depending on the report, these periodic values are aggregated to determine the availability of an NE, interfaces and ports, or service over a period of time. A periodic table tracks the activity state and availability of an NE, interfaces and ports, or service. The availability framework supports the creation of an availability table that aggregates the data in the periodic table based on the periodic synchronization time configured on the system.
The availability framework supporting the availability reports can synchronize objects from the main database to the auxiliary database at a rate of 500,000 objects per minute. The following table shows the number of objects that can be used by the availability framework, based on the Periodic Sync Time.
Table 11-1: The number of objects that can be used by the availability framework based on the Periodic Sync Time
|
analyticsMODictPeriodicSyncTime (min) |
Number of objects that can be used by availability framework |
|---|---|
|
5 |
2,500,000 |
|
10 |
5,000,000 |
|
15 |
7,500,000 |
|
20 |
10,000,000 |
|
30 |
15,000,000 |
|
60 |
30,000,000 |
WARNING: Exceeding the objects per minute limit may result in incorrect availability report content, reports taking a long time to complete, or failing altogether.
It is possible that the synchronization of the data dictionary for the periodic and availability tables does not complete in the allotted time. In this case, the next scheduled resynchronization is skipped, and there may be incorrect availability report content. Any such occurrence is recorded as a warning in the EmsServer.log file on the NFM-P main server (go to /opt/nsp/nfmp/server/nms/log/server/EmsServer.log) with an entry containing “Skipping periodic resync for all enabled Periodic MO dictionary tables”. If such logs occur regularly, you can do one or both of the following:
The following example shows a warning log for a situation in which the periodic Analytics resynchronization for the availability framework attempts to start, but since it is later than its scheduled time, the entire resynchronization is skipped, allowing the next resynchronization to start on time. In this example, the periodic resynchronization should have started at 10:30, but because the previous resynchronization (for 10:15) did not complete on time, the 10:30 resynchronization is skipped (as it is now 10:36), allowing the 10:45 resynchronization to start on time.
<2024.10.18 10:36:32 296 -0400><W><dbupgrade-server--3276818-keepvm><ObjectSynchronizerWorkerPool[20]><server.analytics.AnalyticsMoRsyncManager.resyncAllMOs>[1729262192294] is too late to start the resync for [1729261790976]; skipping periodic resync for all enabled Periodic MO dictionary tables
The number of objects used for the availability framework can be controlled based on the Availability reports in use. Disable periodic monitoring or synchronization of tables used by Availability reports that are not used. For example, if the tables used by the Node Availability Summary and Node Availability Details reports are not required, disable the periodic monitoring of table analytics_network_element, as described in How do I synchronize the Analytics data dictionary table data with the NFM-P for periodic availability monitoring support?.