Unsupported content

 

This version of the product is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Sizing and scalability considerations

Based on the deployment scenarios, the following guidelines contain information about the recommended hardware requirements and configurations for your environments.

Sizing guidelines

This section defines four classes of appliance deployment, which broadly follow how BMC Discovery is deployed in the field. These classes are differentiated by the number of Operating System Instances (OSIs) that are scanned by BMC Discovery. An OSI is a host, switch, router, storage device, printer, and so on.

The names given to these classes are of use only in this document and do not relate to the various editions of BMC Discovery

Note

The following initial guidelines are based on typical deployments of standalone systems in the field, and are intended to serve only as recommended configurations for your environment.

The four classes are:

  • Proof of Concept—Small, time-limited test deployments of BMC Discovery, scanning up to 150 OSIs. The Proof of Concept class has minimal storage allowance as they are only intended for a limited period of scanning such as a week long trial. For longer periods or a continuously used development or UAT system, the Baseline class is the minimum recommended.
  • Baseline—A typical baseline as offered by BMC. Scanning up to 500 OSIs.
  • Datacentre—A typical large scale deployment. Scanning up to 5000 OSIs.
  • Consolidated Enterprise—Enterprise scale deployments, typically a Consolidation Appliance taking feeds from many Scanning Appliances. Typically scanning or consolidating of the order of 20000 OSIs or more. At these levels, a weekly scanning or focused scanning strategy may need to be adopted.

Memory and swap considerations

The recommended figures for memory provide a good level of performance in typical scenarios. The upper level should not be considered a limit, as BMC Discovery will make use of all available memory. Note that the operating system will often make use of some swap, even if there is plenty of RAM available – the use of swap is not in itself a sign that there is insufficient RAM, just a consequence of the operating system optimizing all of its memory resources.

If RAM is available, the OS uses some as a filesystem cache which dramatically improves system performance. As datastore files grow, a correspondingly large increase in RAM can help to maintain levels of performance. In many cases, the datastore files are very large, of the order of 10 to 100 GB. For example, for a large datastore, performance improvements have been seen by increasing RAM from 32 GB to 128 GB and further still to 256 GB.

The recommended figures for swap can be exceeded; there is no harm in doing so, and having more swap can mean more RAM is available for buffers and caches, improving performance. All virtual appliances are initially configured with 8 GB swap. Memory and swap usage depends on the nature of the discovery being performed, with Mainframe and VMware (vCenter/vSphere) devices requiring more than basic UNIX and Windows devices, where the following tables refer to CPUs, full use of a logical CPU (core) is assumed. For example, if eight CPUs are required, then you may provide them in the following ways:

  • Eight virtual CPUs in your virtualization platform, such as VMware Infrastructure.
  • Four dual core physical CPUs.
  • Two quad core physical CPUs.

Appliance sizing guidelines

Resource

POC
(up to 150 OSIs)

Baseline
(up to 500 OSIs)

Datacentre
(up to 5000 OSIs)

Consolidated Enterprise
(scanning or consolidating of the order of 20000 OSIs or more)

CPUs

2

2

8

8

RAM
(GB) available to OS.

2 to 8
(see note below)

8 to 16

16 to 64

64 or more

Swap Space
(GB)

4 to 16

16 to 32

32 to 64

64

DB Disk (GB) - No backup

37

100

1024

1024

DB Disk (GB) - With local backup

37

200

1024

1024

Note

Regarding memory requirements for POC class, 2 GB RAM is sufficient for normal operation, but is insufficient to activate a new TKU. To activate a TKU requires 4 GB of RAM. You can increase the memory for activation and then reduce it for normal operation if required.

Sizing guidelines for virtual and cloud-based appliances

Before deploying any virtual appliance, make sure that you follow these sizing guidelines. In previous releases, sizing guidelines were provided by defining classes of appliance deployment, but these classes are no longer valid for clustered deployments. The earlier sizing guidelines still have some relevance for single appliance deployments but where scale is required, you can use clusters, or add additional machines to an existing cluster.

If RAM is available, the OS uses some as a filesystem cache, which dramatically improves system performance. As datastore files grow, a correspondingly large increase in RAM can help to maintain levels of performance. In many cases, the datastore files are very large, of the order of 10 to 100 GB. For example, for a large datastore, performance improvements have been seen by increasing RAM from 32 GB to 128 GB and further still to 256 GB.

The appliance specification page in the UI retains the classes for standalone deployments but not in clusters. We are reviewing BMC Discovery performance as versions are deployed and might extend our recommendations based on our customers' real experiences.

Note

We recommend that the CPU and RAM resources that are allocated to the BMC Discovery appliance are reserved, and are not shared with other VMware guest operating systems. Otherwise, performance might be inconsistent and might not achieve expectations. For more information, contact your VMware administrator.

Was this page helpful? Yes No Submitting... Thank you

Comments