This topic outlines the hardware capacity recommendations for vertically scaling the BMC TrueSight IT Data Analytics product in your environment.
Notes
The sizing recommendations outlined in this topic are for reference purposes only. These recommendations are meant to be used as a guide for determining your environment-specific sizing estimates.
The sizing estimates provided in this topic are based on performance tests carried out on a virtual setup using Intel® Xeon® CPU E5-2660 @ 2.20GHz processor, with a storage of 300 IOPS. All the results are based on the assumption that data records collected are of the size of 200 bytes per record.
The performance of the product can vary depending on the type of storage and processor used for production configurations. The higher the storage and processor configuration, the better the performance.
Use the following recommendations to plan the hardware capacity required for vertically scaling your deployment.
The hardware sizing guidelines are divided into four parts: nonproduction setups, small setups, medium setups, and large setups.
The nonproduction and small setup scenarios are recommended for a single-server deployment, while medium and large setup scenarios are recommended for a multiple-server deployment. You can also deploy the product in a single-server deployment and later vertically scale the product.
The following table lists the definitions of a medium and large setup:
Size | Daily Indexing volume | Data retention | Concurrent users |
---|---|---|---|
Medium | |||
Scenario 1 | 400 GB per day | 14 days | 8 |
Scenario 2 | 200 GB per day | 16 | |
Large | |||
Scenario 1 | 1 TB per day | 14 days | 8 |
Scenario 2 | 500 GB per day | 16 |
Scaling your deployment is recommended only for medium and large setups while implementing a multiple-server deployment.
If you are operating in a small setup, you can deploy the product in a single-server environment. To understand the hardware recommendations for a single-server deployment (without scaling), see Single-server sizing recommendations.
For a medium setup, you can use a configuration of one server for indexing 400 GB data per day, with a 14-day retention period, and with 8 concurrent users accessing the data.
The following table provides the resource configurations required for implementing this deployment.
Configuration support | Resources |
---|---|
|
|
(x 1 server) |
If you want to retain data for longer than 14 days, then the RAM and disk space configurations need to be increased. For more information, see Long-term data retention recommendations.
For a medium setup with a relatively smaller storage and more number of concurrent users, you can use a configuration of one server for indexing 200 GB data per day, with a 14-day retention period, and with 16 concurrent users accessing the data.
The following table provides the resource configurations required for implementing this deployment.
Configuration support | Resources |
---|---|
|
|
(x 1 server) |
If you want to retain data for longer than 14 days, then the RAM and disk space configurations need to be increased. For more information, see Long-term data retention recommendations.
For a large setup, you can use a configuration of two servers for indexing 1 TB data per day, with a 14-day retention period, and with 8 concurrent users accessing the data.
Use the following guidelines for implementing this deployment:
In this scenario, it is recommended to distribute the product components as follows:
The following table provides the resource configurations required for an individual server. You need to replicate the same configuration on the remaining servers.
Configuration support | Resources |
---|---|
|
|
(x 2 servers) |
If you want to retain data for longer than 14 days, then the RAM and disk space configurations need to be increased. For more information, see Long-term data retention recommendations.
For a large setup with a relatively smaller storage and more number of concurrent users, you can use a configuration of two servers for indexing 500 GB data per day, with a 14-day retention period, and with 16 concurrent users accessing the data.
Use the following guidelines for implementing this deployment:
In this scenario, it is recommended to distribute the product components as follows:
The following table provides the resource configurations required for an individual server. You need to replicate the same configuration on the remaining servers.
Configuration support | Resources |
---|---|
|
|
(x 2 servers) |
If you want to retain data for longer than 14 days, then the RAM and disk space configurations need to be increased. For more information, see Long-term data retention recommendations.
This note is applicable only if you have configured Collection Agents by using the TrueSight console or the PATROL infrastructure. For optimum performance of such Collection Agents, you need to change certain properties based on the number of Collection Agents set up in your environment. The following properties need to be modified: Use the following table as a guideline to determine the preceding property values. These values are based on internal performance tests. Note If you are operating in an environment with 950-1750 Collection Agents, then at a minimum you need two Collection Stations setup on different servers to receive data from those Collection Agents.http.server.workers.thread.pool.size
: Determines the maximum number of concurrent HTTP requests that can be handled by the Collection Station.
This property needs to be added with the new values at %BMC_ITDA_HOME%\station\collection\custom\conf\agent.properties.http.response.timeout.millis
: Determines the period after which the Configuration Channel request must timeout.
This property needs to be added with the new values at %BMC_ITDA_HOME%\agent\collection\custom\conf\agent.properties.agent.request.poll.heartbeat.per.node.retry
: Determines the number of failed HTTP requests before accepting that the Collection Station is not reachable.
This property needs to be added with the new values at %BMC_ITDA_HOME%\agent\collection\custom\conf\agent.properties.Number of Collection Agents http.server.workers.
thread.pool.sizehttp.response.
timeout.millisagent.request.poll.
heartbeat.per.node.retryUpto 450 (Default) 15 (Default) 30,000 (Default) 10 More than 450 and upto 950 60 1,200,000 30 More than 950 and upto 1750
Read more60 1,200,000 30