The following guidelines are based on typical deployments in the field, and are intended to serve only as recommended configurations for your environment.
This section defines four "classes" of appliance deployment that broadly follow how BMC Atrium Discovery is deployed in the field. They are differentiated by how many Operating System Instances (OSIs) that are being scanned by BMC Atrium Discovery. The names given to these classes are of use only in this document and do not relate to the various editions that BMC Atrium Discovery is available in.
The classes are:
- Proof of Concept. Small, time-limited test deployments of BMC Atrium Discovery, scanning up to 150 OSIs.
- 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.
Proof of Concept
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.
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 Atrium Discovery will make use of all available memory. You can determine whether additional memory is needed in your appliance by monitoring swap usage.
If RAM is available, the OS uses some as a filesystem cache which dramatically improves datastore performance. As datastore files grow then a correspondingly large increase in RAM is required 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
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.