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.

Number of agents	Number of CPUs	RAM	JVM process memory	Number of manager nodes	Recommended disk space
<500	2	16 GB	8 GB	2	200 GB
500-1000	4	16 GB	8 GB	2	200 GB
1000-5000	4	16 GB	8 GB	2	200 GB
5000-10000	8	16 GB	12 GB	2	200 GB
10000-20000	8	24 GB	16 GB	2	200 GB

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 platforms on which you install Deep Security Agent.
• 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.

See also Deep Security Manager performance features.

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.

Number of agents	Anti-Malware	Web Reputation Service	Log Inspection	Firewall	Intrusion Prevention System	Application Control	Integrity Monitoring	2 or more modules
1-99	10 GB	15 GB	20 GB	20 GB	40 GB	50 GB	50 GB	100 GB
100-499	10 GB	15 GB	20 GB	20 GB	40 GB	100 GB	100 GB	200 GB
500-999	20 GB	30 GB	50 GB	50 GB	100 GB	200 GB	200 GB	300 GB
1000-9999	50 GB	60 GB	100 GB	100 GB	200 GB	500 GB	400 GB	600 GB
10,000-20,000	100 GB	120 GB	200 GB	200 GB	500 GB	750 GB	750 GB	1 TB

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: async process: 550 per second sync process: 280 per second async file: 1,295 per second sync file: 1,397 per second asyncNetwork: 1.2 per second
vCPU: 4 RAM: 8 GB	Overall: 43% CPU usage per core: 10.75%	4,651 events per second, consisting of the following: async process: 751 per second sync process: 377 per second async file: 1,705 per second sync file: 1,817 per second asyncNetwork: 0.9 per second
vCPU: 8 RAM: 16 GB	Overall: 70% CPU usage per core: 8.75%	5,841 events per second, consisting of the following: async process: 970 per second sync process: 485 per second async file: 2,128 per second sync file: 2,257 per second asyncNetwork: 0.9 per second
vCPU: 16 RAM: 32 GB	Overall: 127% CPU usage per core: 7.9%	6,275 events per second, consisting of the following: async process: 1,011 per second sync process: 505 per second async file: 2,308 per second sync file: 2,450 per second asyncNetwork: 1 per second
vCPU: 32 RAM: 64 GB	Overall: 120% CPU usage per core: 3.75%	4,425 events per second, consisting of the following: async process: 749 per second sync process: 375 per second async file: 1,603 per second sync file: 1,697 per second asyncNetwork: 1 per second
vCPU: 64 RAM: 128 GB	Overall: 96% CPU usage per core: 1.5%	4,346 events per second, consisting of the following: async process: 703 per second sync process: 352 per second async file: 1,600 per second sync file: 1,690 per second asyncNetwork: 1 per second

Deep Security Virtual Appliance sizing

The Deep Security Virtual Appliance software is delivered as a series of Open Virtualization Format (OVF) files, with each file being allocated a different set of resources for different deployment sizes and types. You can use the following table to select the OVF file that best supports your environment.

See also Deep Security Virtual Appliance memory allocation.

OVF file	vCPUs	vRAM	Disk space	Virtual hardware version	NSX type	Maximum protected VMs	DPDK support?
dsva.ovf	2	4 GB	20 GB	13 (ESXi 6.5+)	NSX-V	10	no
dsva-small.ovf	4	8 GB	20 GB	13 (ESXi 6.5+)	NSX-V	50	no
dsva-medium.ovf	6	16 GB	20 GB	13 (ESXi 6.5+)	NSX-V	200	no
dsva-large.ovf	8	24 GB	20 GB	13 (ESXi 6.5+)	NSX-V	300	no
dsva-<20.x.x-xxxx>-C2M4-small.ovf	2	4 GB	20 GB	13 (ESXi 6.5+)	NSX-T	10	no
dsva-<20.x.x-xxxx>-C4M8-small.ovf	4	8 GB	20 GB	13 (ESXi 6.5+)	NSX-T	10 with DPDK enabled 50 with DPDK disabled	yes*
dsva-<20.x.x-xxxx>-C6M16-medium.ovf	6	16 GB	20 GB	13 (ESXi 6.5+)	NSX-T	200 with DPDK disabled	no
dsva-<20.x.x-xxxx>-C8M16-medium.ovf	8	16 GB	20 GB	13 (ESXi 6.5+)	NSX-T	150 with DPDK enabled	yes*
dsva-<20.x.x-xxxx>-C8M24-large.ovf	8	24 GB	20 GB	13 (ESXi 6.5+)	NSX-T	300 with DPDK disabled	no
dsva-<20.x.x-xxxx>-C12M24-large.ovf	12	24 GB	20 GB	13 (ESXi 6.5+)	NSX-T	300 with DPDK enabled	yes*

* To enable Data Plane Development Kit (DPDK) mode, see Configure DPDK mode.

If the appliance is protecting a large number of VMs, and recommendation scans fail due to timeout errors, see Manage and run recommendation scans to increase timeout values.