Sizing
Sizing guidelines for Deep Security deployments vary by the scale of your network, hardware, and software.
Deep Security Manager sizing
Sizing recommendations for Deep Security Manager depend on the number of agents it needs to manage.
For best performance, it is important to allocate enough Java Virtual Machine (JVM) memory to the Deep Security Manager process. See Configure Deep Security Manager memory usage.
Recommendation scans are CPU-intensive for Deep Security Manager. Consider the performance impact when determining how often to run recommendation scans. See Manage and run recommendation scans.
Resource spikes may occur if a large number of virtual machines are rebooted simultaneously and agents re-establish their connection with Deep Security Manager at the same time.
Multiple server nodes
For better availability and scalability, use a load balancer and install the same version of Deep Security Manager on tw0 servers (nodes) connected to the same database.
To avoid high load on database servers, do not connect more than two Deep Security Manager nodes to each database server.
Each manager node is capable of all tasks. No node is more important than any of the others. You can log in to any node; agents, appliances, and relays can connect with any node. If one node fails, other nodes can provide service without any loss of data.
Database sizing
The required database CPU, memory, and disk space depend on the following:
- The number of protected computers.
- The number of events (logs) recorded per second. This is related to the specific security features that are enabled.
- The amount of time during which events are retained.
- The size of the database transaction log.
Minimum disk space = (2 x Deep Security data size) + transaction log
For example, if the size of your database and the transaction log is 40 GB, you must have 80 GB (40 x 2) of free disk space during database schema upgrades.
To free disk space, delete any unnecessary agent packages for unused platforms (see Delete a software package from the Deep Security database), transaction logs, and unnecessary event records.
Event retention is configurable. For security events, retention is configured in the policy, individual computer settings, or both. See Policies, inheritance, and overrides and Log and event storage best practices.
You can minimize disk usage due to events as follows:
-
Store events remotely, not locally. If you need to keep events longer (such as for compliance), forward them to a SIEM or Syslog server and then use pruning to delete the local copy. See Forward Deep Security events to a Syslog or SIEM server.
Some Application Control and Integrity Monitoring operations (Rebuild Baseline, Scan for Integrity Changes, and Scan for Inventory Changes) retain all records locally, and are never pruned or forwarded.
- Patch the protected computer's software before you enable Intrusion Prevention. Recommendation scans assign more IPS rules to protect a vulnerable OS. More security events increase local or remote disk usage.
- Disable unnecessary security features that log frequently, such as stateful Firewall for TCP, UDP, and ICMP.
High-traffic computers that use Deep Security Firewall or Intrusion Prevention features might record more events per second, requiring a database with better performance. You might also need to adjust local event retention.
If you anticipate many Firewall events, consider disabling Out of Allowed Policy events. See Firewall settings.
Database disk space estimates
The following table estimates database disk space with default event retention settings. If the total disk space for the enabled protection modules exceeds the value of 2 or more modules, use the smaller estimate. For example, you could deploy 750 agents with Deep Security Anti-Malware, Intrusion Prevention System, and Integrity Monitoring. The total of the individual recommendations is 320 GB (20 GB + 100 GB + 200 GB), but the 2 or more modules recommendation is 300 GB. Therefore, you would estimate 300 GB.
Database disk space also increases with the number of separate Deep Security Agent platforms. For example, if you have 30 agents (maximum 5 versions per agent platform), this increases the database size by approximately 5 GB.
Deep Security Agent sizing and resource consumption
To ensure optimal performace, Deep Security Agents and relays need to have certain amount of CPU, RAM, and disk space allocated to them.
Deep Security Agent and Relay sizing
For Deep Security Agent and relay requirements with regards to CPU, RAM, and disk space allocation, see Deep Security Agent requirements and Deep Security Relay requirements.
Estimated Deep Security Agent resource consumption
The following tables show the estimated RAM consumption for deployments using common feature combinations.
Windows Agent
| Modules enabled | RAM | |||||||
| Anti-Malware | Web Reputation Service | Activity Monitoring | Application Control | Integrity Monitoring | Log Inspection | Firewall | Intrusion Prevention | |
| ✔ | 156 MB | |||||||
| ✔ | 148 MB | |||||||
| ✔ | ✔ | ✔ | 150 MB | |||||
| ✔ | ✔ | ✔ | ✔ | 308 MB | ||||
| ✔ | ✔ | ✔ | ✔ | 280 MB | ||||
| ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | 390 MB | |
| ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | 361 MB |
Linux Agent
| Modules enabled | RAM | |||||||
| Anti-Malware | Web Reputation Service | Activity Monitoring | Application Control | Integrity Monitoring | Log Inspection | Firewall | Intrusion Prevention | |
| ✔ | 315 MB | |||||||
| ✔ | ✔ | 172 MB | ||||||
| ✔ | ✔ | 399 MB | ||||||
| ✔ | ✔ | ✔ | 312 MB | |||||
| ✔ | ✔ | ✔ | ✔ | 448 MB | ||||
| ✔ | ✔ | ✔ | ✔ | 413 MB | ||||
| ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | 492 MB | ||
| ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | 538 MB | |
CPU sizing for Anti-Malware Solution Platform service
Deep Security Agent triggers a security update automatically when the Anti-Malware Solution Platform (AMSP) service is ready, which occurs if at least one of the following modules is enabled:
- Anti-Malware
- Activity Monitoring
- Application Control
- Integrity Monitoring
Based on the testing of agents on Linux conducted by Trend Micro, the following can be concluded:
- The overall CPU usage by AMSP is around 10%. This includes the process creation, file operation, and network operation events.
- Different CPU consumption calculation methods may lead to greater CPU usage results, therefore it is recommended to take a per-core approach (CPU consumption divided by the number of cores).
The following table provides detailed test results of the Linux agents' AMSP CPU consumption and event handling capabilities for different VM combinations, all using common policies (such as AM, SENSOR, WRS).
| VM specifications | CPU usage by AMSP | Workload events per second |
|---|---|---|
|
vCPU: 2 RAM: 4 GB |
Overall: 23% CPU usage per core: 12.5% |
3,523 events per second, consisting of the following:
|
|
vCPU: 4 RAM: 8 GB |
Overall: 43% CPU usage per core: 10.75% |
4,651 events per second, consisting of the following:
|
|
vCPU: 8 RAM: 16 GB |
Overall: 70% CPU usage per core: 8.75% |
5,841 events per second, consisting of the following:
|
|
vCPU: 16 RAM: 32 GB |
Overall: 127% CPU usage per core: 7.9% |
6,275 events per second, consisting of the following:
|
|
vCPU: 32 RAM: 64 GB |
Overall: 120% CPU usage per core: 3.75% |
4,425 events per second, consisting of the following:
|
|
vCPU: 64 RAM: 128 GB |
Overall: 96% CPU usage per core: 1.5% |
4,346 events per second, consisting of the following:
|