This documentation supports the 20.08 (12.1) version of BMC Discovery.To view an earlier version of the product, select the version from the Product version menu.

Hardware requirements


This topic provides guidance on the hardware specifications you must follow for getting the best BMC Discovery scanning performance.  This topic also discusses on the ability to cluster discovery machines, which is related to scaling BMC Discovery to scan larger estates across multiple appliances.

What hardware should I run BMC Discovery on?

  1. When planning how to spend your hardware budget, we recommend prioritizing fast disks. This is because when actively scanning, BMC Discovery places a heavy read-and-write load on the database. BMC Discovery's performance benefits greatly from giving it the fastest disks possible; the slower your disk I/O, the slower BMC Discoveryperformance will be. For example:
    1. Local Solid-State Disks: Solid-State Disks (SSDs) local to the appliance are likely to be the fastest option. This is true for physical as well as virtual appliances where the hypervisor's datastores map to SSDs that are local to the hypervisor.
    2. Remote Storage Area Network: Although Remote Storage Area Network is likely to be slower than local SSDs, it can be a good choice, assuming that the storage is close in network terms to the consuming appliance. Again, SSDs will be faster than Hard Disk Drives (HDDs).
    3. Local Hard Disk Drive: Local HDDs are likely to be the cheapest, but also the slowest option. If forced to use HDDs, then always use the fastest possible.
  2. After disk, the other factors influencing BMC Discovery performance are increasing RAM, CPU speed, and the number of CPU cores. We attempt to scale worker processes based on the hardware profile we detect.
  3. It is best to increase specifications across the board, otherwise any one element may become the bottleneck. For example, there is little to be gained by putting two modern 12-core Xeons in a machine with only 4 GB RAM. Instead, balance the investment between CPU, RAM, and disk.
  4. BMC Discovery runs well on a variety of platform specifications. With BMC Discovery deployed as a VM, if you allocate hardware resources better, BMC Discovery can:
    1. scan faster
    2. be more responsive to logged-in users
    3. store more data
  5. Choose the disk size according to how much you need to scan and how much directly discovered data history you want to retain. 
  6. CMDB synchronization supports multiple CMDB connections. Disk space consumed for each device (for example, a host node) for each connection, is typically 200 KB, though this may vary depending on your data.
  7. As a rough guideline, you can scan an environment of 10,000 to 15,000 machines every day with a single BMC Discovery appliance running on reasonable hardware.
  8. For very large estates consider a clustered solution. 

Minimum hardware to run a non-production deployment

For non-production deployment of BMC Discovery, such as proof-of-concept (POC) or other throw-away deployments, the discovery appliance will run on the following minimum hardware specification:

RAM

8 GB

Cores

2

CPU speed

Any 64-bit processor

Disks

50 GB

Network

100 Mb Ethernet

Minimum hardware to run a production deployment

The following hardware specification is for a production deployment of BMC Discovery:

RAM

64 GB

Cores

8

CPU speed

Server-grade CPUs

Disks

1 TB SSD

Network

Gigabit Ethernet

Clustering

BMC Discovery clustering enables you to use two or more machines to increase the scanning speed, system responsiveness, and the total amount of data that can be handled. BMC Discovery can help you reach levels of scale not achievable with current hardware on a single machine or allow you to reach the same scale with cheaper hardware.

Memory and swap

Memory and swap usage depend on the nature of the discovery performed, with Mainframe, cloud, storage and VMware (vCenter/vSphere) devices requiring more than basic UNIX and Windows devices. You can determine whether additional memory is needed in your appliance by monitoring swap usage.

There is no harm in exceeding the recommended figures for swap. It might prove simpler to configure the higher quantity of swap than to extend an existing swap partition as this will allow the RAM demand to be derived as above. All virtual appliances are initially configured with 8 GB swap.

The underlying OS will tend to use up all of the available memory, it uses memory for applications and for caching, which is essentially buffering data. 


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*