How nodes are removed

It is important that the model of your network environment stays current over time and that it is maintained efficiently. This not only involves creating new nodes to represent recently discovered data, but also the removal of existing data that is no longer present in your environment. BMC Discovery views the environment so that different kinds of nodes are removed in different ways. Different methods are used to remove inferred nodes and Directly Discovered Data nodes from the model. These variations in behavior are detailed in the following sections.

Note

For patterns as well as the overall functioning in BMC Discovery, if the system scans the infrastructure and captures some data but in a subsequent scan fails to obtain the same data, it does not immediately remove the old data. For example, a scan in the past may have captured a host and its installed packages. But the latest scan may fail to retrieve the packages. This does not mean that the host now has no installed packages. The system records the failure in DDD and leaves the existing data as the best-known information. In a subsequent scan if the system successfully gets a list of packages, and some packages that were previously present are now absent, then the system updates the data by removing the relationships to non-existing packages.

Inferred nodes removal

The following sections detail the ways in which inferred nodes are removed from BMC Discovery. For more information on inferred nodes, see Inferred-nodes.

Manual

To remove a node manually, select it in the node list and pick Destroy from the Actions list.

Authoritative

BMC Discovery has inferred the presence of a node from data such as an interface list, where there is clear evidence that the node exists. When BMC Discovery cannot see any evidence of this node, it no longer exists. Therefore, BMC Discovery removes the node automatically from the model. Aging is not applied to this type of removal.

Non-authoritative (aging)

BMC Discovery has inferred the presence of a node from data such as a process list, where there is clear evidence that the node exists. However, when BMC Discovery cannot see evidence that the node still exists, it does not necessarily imply that the node no longer exists. There might be other reasons why the node appears to no longer exist.

For example, a process related to a software instance (SI), such as an Adobe FrameMaker desktop application, might appear to be running during an initial scan but not on a subsequent one. This does not necessarily indicate that Adobe FrameMaker no longer exists; instead, the user may have stopped running the application during the subsequent scan. Because it is the nature of IT infrastructure to have frequent minor changes to configurations, hosts, and software, discovered data becomes less relevant over time.

Aging is applied to this type of removal to prevent frequent removal and recreating of SIs. When the node has been in the aging state for some time, it is then removed from the model.

Only the following classes of nodes age:

Root nodes (Host, Network Device, MFPart, Printer, SNMP Managed Device, and Management Controller.)
First order Software Instances (ones created directly from DDD)
Runtime Environment
Storage

The Software Instance, Runtime Environment, and Storage nodes mentioned above are only automatically aged if triggered on certain DDD types. These are described on the individual node pages.

Although important considerations must be made before doing so, you can modify data aging limits in the user interface's Model Maintenance settings.

Secondary authoritative

This type of removal is authoritative, however it is based on different criteria than the original evidence for its existence.
An example of this would be a batch process, where a node creation (and therefore existence) is triggered from seeing the job running in the process list, but BMC Discovery might check the timestamp of a log file to see if it believes it is running regularly.

This type will apply to any removal which involves actively seeking evidence about whether something exists.

Containment

This type of removal applies when BMC Discovery has inferred nodes which have a containment relationship to another node. These are generally nodes which model physical items such as network interface cards. If the non-authoritative removal process (Aging) has caused BMC Discovery to remove a host, then the network interfaces that are contained in that host will also cease to exist. Therefore, Aging is not applied and the inferred node is removed.

Cascade

This type of removal applies where further inferred nodes are constructed from first order or other inferred nodes. Any aging or specific removal will already have taken place at the first order nodes, so there is no need to apply any further removal strategies. In this case the removal should cascade up.

Directly Discovered Data nodes removal

The removal process for DDD-nodes, is a much simpler process than it is for Inferred nodes.

The five removal strategies for Inferred nodes calculate that the entity in the real-world to which the data corresponds no longer exists and, therefore, the node is removed. Each time you run a discovery of DDD nodes, a new set of data is retrieved. If the data is older than a certain cut-off point and BMC Discovery discovers more recent data that refers to the same node, the node is removed.

Removal of nodes in systems consolidating the inferred model

In systems consolidating the inferred model, when a node that is based only on consolidated data is removed from the sender, it is also removed from the receiver. However, where other sources contribute to that node on the receiver, such as integration with BMC Helix Operations Management, the node is not removed.

The consolidated DDD nodes (Discovery Run and Discovery Access nodes, which contain information about the discovery itself rather than the discovered target) are removed according to DDD aging on the receiver.

If the model is wiped in the sender (tw_model_wipe), no data is removed from the receiver. A sender sends change events to the receiver which updates its model accordingly. A tw_model_wipe is performed offline, so no change events are sent. If the configuration on the sender is preserved in the tw_model_wipe operation, the sender reconnects to the receiver. When it reconnects, a resync is required. If performed, that resync deletes all the data based only on that consolidation connection.

Removal groups in the pattern language

When patterns construct complicated structures, such as DatabaseDetail nodes when doing deep discovery of databases, removal must be performed by the pattern that creates them. Removal Groups are named groups of nodes which simplify deletion of these complex structures. They are described in Model-functions in the TPL Guide.