Configuring model maintenance settings

You can modify settings for maintaining your data model, including aging limits, in the Model Maintenance settings of the user interface.

Note

Datastore cache

In previous versions, the datastore cache setting required manual configuration. It is now managed automatically.

To configure model maintenance settings:

From the main menu, click the Administration icon.
The Administration page opens.

In the Model section, click Model Maintenance.

The options on the page are described in the following table.

Field Name	Details
Directly Discovered Data removal	Specify the age past which Discovery Accesses and all the related DDD nodes are removed (the default is 28 days). • Quarterly (90 days) • Monthly (28 days) • Fortnightly • Weekly If the setting does not match one of these options the value will be shown as "--custom settings--". In a demonstration appliance only, the default setting for aging is Never, meaning that demonstration data never ages out of the system. This setting is not available for any other type of appliance, and demonstration appliances should never be used for anything other than demonstrations. For guidelines, see Modifying DDD, host, and software instance aging limits.
Time before destroyed nodes are purged	Specify the time elapsed before destroyed nodes are purged from the datastore. The default is one year. To change this, choose one of the following periods from the drop-down list. • Never • 30 days • 90 days • 180 days • One year • Two years
Time before history entries are purged	Specify the time elapsed before history entries are purged from the datastore. The default is never. To change this, choose one of the following periods from the drop-down list. • Never • 30 days • 90 days • 180 days • One year • Two years
Scan optimization timeout	When an IP address is designated the preferred IP address for a host, Discovery does not perform scans on other known IP addresses for that host. This is referred to as scan optimization. After a specified Scan optimization timeout period, Discovery will scan other known IP addresses for that host to ensure that they are still non-preferred and on the same host. BMC Discovery reuses the last successful credential until the Scan optimization timeout expires. It attempts to use other credentials afterwards. The default is seven days. Specify one of the following timeout periods from the drop-down list. • 1 - 10 days • 14 days • 21 days
Device aging time limit	Specify the aging time limit for host, network device, storage device, printer, SNMP managed device, mainframe, and management controller nodes. This value must be higher than the Scan optimization timeout. The default is 10 days. • 2 - 10 days • 14 days • 21 days • 28 days For guidelines, see Modifying DDD, host, and software instance aging limits.
Device aging access failures	Specify the access failure limit for for host, network device, storage device, printer, SNMP managed device, mainframe, and management controller nodes. The default is seven failures. • 1 - 10 failures
Time to elapse before a software instance/container/virtual machine/runtime environment/storage can be aged	Specify the time to elapse before a software instance/runtime environment/storage node can be aged. (the default is 10 days). • 1 - 20 days • Steps of 5 to 100 days For guidelines, see Modifying DDD, host, and software instance aging limits.
Minimum number of failed accesses before a software instance/container/virtual machine/runtime environment/storage is aged	Failed accesses before a software instance/runtime environment/storage node is aged. • 1 - 20 failures • Steps of 5 to 45 failures
Number of credential failures that count as one failed access	In situations where a credential on a host (or network device, printer, and so on) is changed on the host but the corresponding access credential is not updated in BMC Discovery, the host or device might age out of the model quite quickly, although it is still there and responding, though BMC Discovery cannot access it. This option slows down the device aging (Device aging access failures above). For example, using the default of five, the device becomes eligible to age out after five times the value of Device aging access failures (5 * 7 = 35). The elapsed time limit (Device aging time limit above) is still respected. If there is no response from the device, aging occurs normally. The default is five failures. Specify one of the following from the drop-down list. • 1 failure • 2 failures • 3 failures ... • 10 failures
Size Warning	The maximum size of the datastore. When this limit is reached, a warning is displayed in the Appliance Status page. This is a soft limit and does not prevent the datastore growing beyond the specified limit. You can select any value from 10 to 100 GB in steps of 5 GB from the list. The default is 30 GB.
Checkpoint Interval	The interval between datastore checkpoints. The larger the interval, the more data has to be written to the checkpoint files. The smaller the interval, less data needs to be written to the checkpoint files, though the writing takes place more often. The default is 15 minutes. You must contact Customer Support before you make any changes to this setting.

Modifying DDD, host, and software instance aging limits

In general, the expectation that BMC Discovery uses for deriving the default model maintenance settings is based on performing one scan of the estate every 24 hours with a DDD depth of one month. This expectation is also used to derive the sizing data. The default setting for data aging for both hosts and software instances is 10 days, because for most deployments this limit provides the best balance of responsiveness without data thrashing. Putting this in a business example, this gives two weekends plus additional time to detect that a host is aging, investigate why it is doing so, and make changes before the host is destroyed. It gives the software teams the same length of time to sort out any failures in the estate.

Best Practice

We recommend that you do not attempt to fine-tune model maintenance parameters. Doing so can make BMC Discovery highly reactive and have negative consequences, such as causing a dramatic increase in the size of the datastore and putting more load on your target estate. If you do alter the model maintenance parameters, we recommend that you do not vary more than half or twice the standard settings detailed in the preceding table.

However, there might be occasions when modifying the defaults are necessary, particularly if you scan your estate at different intervals and need to keep close control on disk consumption. The following table shows recommended settings based on your scanning frequency.

Scanning Frequency	Recommended Aging Limit
Every 2 days	Maintain DDD at 28 days, and decrease the Host and Software Instance access failures to 4 (to account for half as many expected scans).
2 times per day	Decrease DDD to 14 days (to cap how much space it consumes, unless you increase the disk space to more than the sizing guidelines); increase the Host and Software Instance access failures to 12-14 (to account for scanning at twice the expected rate).

For more information about aging and how it fits in the node removal process, see How nodes are removed.

Scheduled DDD aging

In BMC Discovery systems where discovery (or consolidation) is in progress for most of the available time, contention between the removal (aging out) of DDD nodes (in this case Discovery Access nodes and their children) and the creation of new nodes, might affect the performance of in-progress discovery runs. To avoid this performance impact you can schedule DDD removal blackout windows during which no DDD removal is undertaken.

When should DDD removal blackout windows be used?

DDD removal blackout windows should typically only be used on consolidation appliances when you need to achieve maximum discovery throughput. In virtually every discovery schedule used, the continual aging scheme used by BMC Discovery can remove "old" DDD at a similar rate as they are created.You can determine whether scheduling DDD removal blackout windows might be beneficial using the DDD removal statistics page. The DDD removal statistics page shows the total number of DiscoveryAccesses in the datastore and those eligible for removal. If DiscoveryAccess removal is keeping up with DiscoveryAccess creation, then the number of eligible Discovery Access nodes is zero, or near zero, DDD removal blackout windows are not required. If the trend of eligible DiscoveryAccess is rising over a two week period, then DDD removal blackout windows might be a solution. See DDD removal statistics page for more information.

Viewing existing DDD aging blackout windows

From the main menu, click the Administration icon.
The Administration page opens.
In the Model section, click Model Maintenance.
Select the DDD Removal Blackout Windows tab.

When you view the DDD Removal Blackout Windows tab, the active blackout window is highlighted. If multiple blackout windows are active, the one with the longest time remaining before it ends is highlighted. This is not automatically refreshed.

DDD nodes are removed in batches which are not interrupted. Once removal starts, it continues to completion. Therefore, if a batch removal is in progress at the beginning of a DDD removal blackout window, it will continue into the blackout until completion. In normal operation this should take no more than a few minutes.

Adding a new DDD aging blackout window

You can schedule a new DDD aging blackout window to occur daily, weekly, or monthly and can specify a start time and duration.

Click the Add button.
The Add a New DDD Removal Blackout Window dialog box is displayed.

Enter the information for the blackout window in the fields described in the following table.

Field Name	Details
Comment	Enter a descriptive comment for the blackout window.
Frequency	Select a frequency for the window to operate. For example, this can be Daily, Weekly, or Monthly. For a weekly blackout window, you are provided with buttons for each day. Select the day or days that you want the window to operate. For a monthly blackout window, you are provided with buttons for each day in the month. Select the day or days that you want the window to operate. Alternatively, select the No Removal On The radio button and choose one of: • First • Second • Third • Fourth • Last and the day that you want the window to operate. In this way you can select the Second Tuesday of the month and so forth.
Start Time	Select a time for the window to start.
Duration	Select a duration in hours. This is the length of time that the blackout window operates and can be from 1 to 24 hours. For a daily blackout window the maximum number of hours you can select is 23. This prevents you from inadvertently scheduling a 24/7 blackout.

Click OK.