Sizing Linux
You must consider several core technologies when sizing a BMC Cloud Lifecycle Management environment. Sizing of each product in the value path is based on the individual load on each product's sample use case, as described in the following table. The following topics are covered in this section:
Sizing by deployment type
The following table explains the sizing requirements for each product in the solution.
Note
Deployment type | Number of managed devices | Rate of Change (VM Create, Update, Retire) | Concurrent Cloud Admins | Concurrent Cloud End Users |
---|---|---|---|---|
Compact Deployment (if you use an external database) | 5,000 | 50 per hour | 5 | 25 |
Small | 10,000 | 50 per hour | 10 | 50 |
Medium | 25,000 | 100 per hour | 50 | 250 |
Large | 50,000 | 250 per hour | 250 | 500 |
Application tier hardware sizing
Note
The table below describes the number of nodes needed for each deployment size.
Cloud component | Small | Medium | Large |
---|---|---|---|
BMC AR System Server – Cloud Portal and Database (Cloud Portal and Database) | 2 VCPU 2+GHz x1 | 4 VCPU 2+GHz x2 | 4 VCPU 2+GHz x3 |
Cloud Portal and Database Mid Tier RHEL 6.3 (64-bit) Oracle JDK/JRE 1.6.0_20 Apache 2.2 (32-bit) Tomcat 6.0.26 (64-bit) BMC Remedy AR System Mid-Tier 8.1 SP1 | 2 VCPU 2+GHz x1 4 GB RAM 60 GB Disk | 2 VCPU 2+GHz x2 4 GB RAM 60 GB Disk | 2 VCPU 2+GHz x3 4 GB RAM 60 GB Disk |
Cloud Platform Manager | 4 VCPU 2+GHz x1 | 8 VCPU 2+GHz x1 | 8 VCPU 2+GHz x2 |
Atrium Core - Web Registry Components | 4 VCPU 2+GHz x1 | 4 VCPU 2+GHz x2 | 4 VCPU 2+GHz x2 |
BMC Server Automation Application Server | 8 VCPU 2+GHz x1 | 8 VCPU 2+GHz x2 | 8 VCPU 2+GHz x3 |
BMC Server Automation File Server | 4 VCPU 2+GHz x1 | 4 VCPU 2+GHz x2 | 4 VCPU 2+GHz x2 |
BMC Network Automation | 2 VCPU 2+GHz x1 | 2 VCPU 2+GHz x2 | 4 VCPU 2+GHz x2 |
BMC Atrium Orchestrator (CDP + CDP HA) | 4 VCPU 2+GHz x1 | 4 VCPU 2+GHz x2 | 4 VCPU 2+GHz x3 |
Note
BMC Server Automation App Server | 8 VCPU2+GHz | 8 VCPU2+GHz | 8 VCPU2+GHz |
Database Tier Hardware Sizing Information
Physical servers are required for the database servers. We do not recommend running databases on virtualized hardware.
Customers may choose to host product databases on single physical server or on separate servers. The decision is based on multiple factors, including, but NOT limited to H/W and Licensing cost, performance, administration & maintenance efforts and security requirements.
Sizing for separate database servers
Note
If customers choose to host product databases on separate servers, see the sizing (and number of DB servers) mentioned below:
Cloud Component | Small | Medium | Large |
---|---|---|---|
Cloud Portal and Database Server + | 8 CPU-Cores 2+GHz | 16 CPU-Cores 2+GHz | 32 CPU-Cores 2+GHz |
BMC Server Automation Database | 4 CPU-Cores 2+GHz | 8 CPU-Cores 2+GHz | 8 CPU-Cores 2+GHz |
BMC Network Automation Database | 2 CPU-Cores 2+GHz | 4 CPU-Cores 2+GHz | 4 CPU-Cores 2+GHz |
Sizing for single database server
If customers choose to host product databases on a single server, see the sizing (and number of DB servers) mentioned below:
Database Instance | Compact | Small | Medium | Large |
---|---|---|---|---|
Database Server | 8 VCPU 2+GHz x1 | 16 CPU-Cores 2+GHz x1 | 32 CPU-Cores 2+GHz x2 | 64 CPU-Cores 2+GHz x2+N |
Note
- The disk size mentioned above indicates disk space consumed by the data and indexes. Please include additional space for OS and other software installed. Below is approximate distribution between data and index space for reference purpose:
- For BMC Server Automation database: 40% Data , 60% Index
- For BMC Network Automation, Cloud DB and Enterprise AR server databases: 60% Data and 40% Index
- Atrium Web Registry database is not very transactional in nature and hence much smaller in size. For all Small, Medium and Large deployments, this database can be installed on the same Oracle server instance.
- The sizing above is based on benchmark tests for CLM specific use cases only
- Transaction Log sizing is mainly driven by two factors. Customers should size transaction log files based these factors:
- Database recovery model
- DB backup strategy and frequency
Comments
Log in or register to comment.