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 being scanned by BMC Discovery. The names given to these classes are of use only in this document and do not relate to the various editions of BMC Discovery. The four classes are:
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.
- 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 then 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
4 to 8
2 to 4
4 to 8
8 to 16
16 to 32 or more
4 to 8
8 to 16
16 to 32
16 to 32
DB Disk (GB) - No backup
200 to 660
DB Disk (GB) - With local backup
450 to 1300
The disk configuration utility uses the following calculation to determine the best swap size.
- Where the amount of memory is less than 16 GB swap size is set at double the memory size.
- Where the amount of memory is between 16 and 32 GB swap is set at 32 GB.
- Where the amount of memory exceeds 32 GB swap is set to equal them memory.
The disk requirement with local backup is lower than in previous versions as the appliance backup feature does not use as much disk space as appliance snapshot when creating the backup.
Memory requirements for POC class
2GB RAM is sufficient for normal operation, but is insufficient to activate a new TKU. To activate a TKU requires 4GB of RAM. You can increase the memory for activation and then reduce it for normal operation if required.