Sizing guidelines for Deep Security deployments vary by the scale of your network, hardware, and software.

Deep Security Manager sizing

The sizing recommendations for the Deep Security Manager computer depends on the number of agents that are being managed:

Number of agents Number of CPUs RAM JVM process memory Number of manager nodes Recommended disk space
<500 2 8 GB 4 GB 2 200 GB
500-1000 4 8 GB 4 GB 2 200 GB
1000-5000 4 12 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
  • Two manager nodes are recommended to provide redundancy and ensure the availability of the manager services.
  • To ensure adequate performance during concurrent operations, you should install Deep Security Manager and the database on separate, dedicated servers in the same physical location.
  • Java Virtual machine (JVM) memory allocation is important for Deep Security Manager performance. To change the default allocated memory for the Deep Security Manager JVM process, see Configure Deep Security Manager memory usage.
  • Recommendation scans are CPU-intensive for the Deep Security Manager. The performance impact to the Deep Security Manager should be taken into consideration when determining how often to run recommendation scans. For more information, 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 in larger deployments, use a load balancer, and install the same version of Deep Security Manager on multiple servers ("nodes"). Connect them to the same database storage.

To avoid high load on database servers, don't 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, and agents, appliances, and relays can connect with any node. If one node fails, other nodes can still provide service, and no data will be lost.

Database sizing

Several variables affect database disk space requirements:

  • Number of computers
  • Number of events (logs) recorded per second
  • How long events are retained

Event retention settings can be configured in the policy, the individual computer settings, or both. (See Policies, inheritance, and overrides.) To configure disk space usage, see Limit log file sizes, including which events are logged for stateful Firewall of TCP, UDP, and ICMP.See also Deep Security Manager performance features.

The database sizes in the following tables are suggestions for use with the default settings for log and event retention (7 days). Follow these steps to estimate sizing for your database:

  1. Identify the protection modules you are enabling and the number of agents that you are deploying.
  2. Add the individual recommendations for each protection module to estimate the database size.
  3. Compare this value with the "2 or more modules" recommendation and provision the lesser of the two

For example, you are deploying 750 agents with Anti-Malware, Intrusion Prevention System and Integrity Monitoring. The total of the individual recommendations is 320 GB (20 + 100 + 200). However, the "2 or more modules" recommendation is 300 GB. Therefore, you should provision 300 GB.

Disk space estimates

Number of
Anti-Malware Web
Firewall Intrusion
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 sizing considerations

  • By default, data pruning is not performed on system events, which have a large impact on the database size. Adjust pruning settings according to your compliance requirements. (See Log and event storage best practices.)
  • If you require long retention requirements for system events, use SIEM or Syslog servers for event forwarding. You can also use SEIM or Syslog servers for Security Control event forwarding. (See Forward Deep Security events to a Syslog or SIEM server.)

    When system events and Security Control events are forwarded to SIEM or Syslog servers, they are not deleted from the database. To delete these events use data pruning.

  • To conserve disk space, delete all agent configuration packages for each platform that are not in use. For more information, see Delete a software package from the Deep Security database. If you need to keep the configuration packages, add disk space accordingly. To help with estimating disk space requirements, consider a newly-installed Deep Security Manager with co-located relay that is assigned a policy that protects a Manager computer. When 29 agents (maximum 5 versions per agent platform) are added, the database size grows approximately 5 GB.
  • The Rebuild Baseline, Scan for Integrity Changes, and Scan for Inventory Changes operations retain all records in the database and are never pruned or forwarded to external Syslog or SIEM systems. The Application Control and Integrity Monitoring security modules use these operations and therefore require more storage space than other security modules. Other types of operations, such as system or security events, are pruned or forwarded to external Syslog or SIEM systems.
  • High-traffic environments that use the Firewall and Intrusion Prevention modules can cause a large number of related events. Factors that influence the number of events are the number of applied Intrusion Prevention rules and Firewall rule configuration. Because these events can require significant database storage, you should monitor these security events and use suitable data pruning.
  • Intrusion Prevention rules are applied based on vulnerabilities assessed during a recommendation scan. You can reduce the number of rules assigned by regularly patching your system and keeping applications up to date.
  • If you anticipate a significant number of Firewall events, consider disabling "Out of allowed policy" events. (See the Advanced section in Firewall settings.)

Deep Security Agent and Relay sizing

Platform Features enabled RAM Minimum disk space
Windows All protection 2 GB (4 GB recommended) 1 GB
Windows Relay only 2 GB (4 GB recommended) 30 GB
Linux All protection 1 GB (5 GB recommended) 1 GB
Linux Relay only 1 GB (4 GB recommended) 30 GB
Solaris All protection(1) 4 GB 1 GB

(1) Relay functionality is not supported

  • Requirements vary by OS version, so some may require less RAM. Less RAM is also required if you are not enabling all of the Deep Security features.
  • The Deep Security Relay must store packages for each of your agents' platforms. For more information, see Get Deep Security Agent software. If you have many different platforms, more disk space is required. For information on the number of relays you should use, see Distribute security and software updates with relays.
  • If V-Motions are expected, another 10 GB is recommended for a total of 40 GB.

Deep Security Virtual Appliance sizing

By default, the Deep Security Virtual Appliance has only 4 GB of memory. The number of virtual machines that a Deep Security Virtual Appliance is protecting determines the hardware requirements of the appliance. The following table lists the minimum number of vCPUs and amount of memory to allocate based on the number of protected virtual machines. To allocate memory for virtual appliances, see Deep Security Virtual Appliance memory allocation.

Number of protected virtual machines Number of vCPUs RAM Minimum disk space
1-25 2 6 GB 40 GB
26-50 2 8 GB 40 GB
51-100 2 10 GB 40 GB
101-150 4 12 GB 40 GB
151-200 4 16 GB 40 GB
201-250 6 20 GB 40 GB
251-300 6 24 GB 40 GB

The workloads above are supported by Deep Security, with the following stipulations:

  • If you want agentless Integrity Monitoring, you'll need a deployment of 0-50 VMs per ESXi server. For larger VDI deployments (approximately 51-300 servers), Integrity Monitoring should be turned off. If you have a VDI deployment and need Integrity Monitoring, we recommend deploying agents on each of your VMs.
  • If you want to use agentless Anti-Malware scanning, you'll need VMware's Guest Introspection capability. Guest Introspection may support different workloads from the ones described in the table above. For details, see the VMware Configuration Maximum tool.
  • If you want to use agentless Firewall, Web Reputation, or Intrusion Prevention features, you'll need VMware's Network Introspection capability. Network Introspection may support different workloads from the ones described in the table. For details, see the VMware Configuration Maximums tool.

We recommend that you patch the OS under protection (especially Windows) before turning on Intrusion Prevention. An unpatched OS results in a larger number of Intrusion Prevention rules assigned to the VMs and increases the appliance's memory usage. The memory recommendation for 300 protected VMs is based on approximately 350 to 400 Intrusion Prevention rules being assigned per VM. If a recommendation scan recommends more rules, you should increase the Deep Security Virtual Appliance memory accordingly. For example, here are approximate recommendations for 300 VMs targeting VDI (full, linked or instant clones):

Number of Intrusion Prevention rules Appliance memory
350-400 24 GB
500-600 30 GB
600-700 40 GB
700+ 50 GB

Running recommendation scans on all 300 protected VMs may result in timeouts. If you find that recommendation scans are failing due to timeout errors, follow the instructions in Manage and run recommendation scans to increase timeout values.