What considerations are there for using the network-based Shared Insight Cache server?
About Shared Insight Cache (SIC)
The SIC server works with Symantec Endpoint Protection (SEP) 12.1 clients, especially in virtualized environments, to improve on-demand scan performance. SEP clients can be configured to request information on unknown files and submit information on known files to/from the SIC. The SEP client performs these lookups during all scheduled and on-demand scans. This allows the the client to substitute a small amount of network traffic for a larger amount of disk I/O by not scanning files another SEP client has already scanned and determiend to be safe.
Note: The SIC feature is designed for use in highly homogenous, virtualized environments. It is considered best practice to utilize this feature only in such environments. Network-based SIC may be implemented for physical clients if desired, but the network impact may outweigh the potential I/O bandwidth gains.
Network-based SIC server system requirements and recommendations
The network-based SIC server is designed to run on a stand-alone physical or virtual machine, and should not be installed to a system running other database applications or high-availability server applications, such as Symantec Endpoint Protection Manager (SEPM) or Microsoft SQL Server. See System requirements for network-based Symantec Shared Insight Cache Server for official system requirements.
Network-based SIC server CPU, memory and disk usage considerations
The network-based SIC server stores all file information in memory to provide the best performance possible. Memory usage will grow until the SIC is reset, or reaches the maximum amount available to the process (2 GB on 32-bit Windows, 8GB on 64-bit Windows). Disk space usage is minimal and does not grow over time.
Expected memory usage for a network-based SIC server serving less than 100 clients is expected to be 2GB or less. network-based A SIC server serving 100-1000 clients will use 4 GB or more. For network-based SIC servers with more than 1000 clients, expect 8GB or larger memory loads. 64-bit Windows is recommended for any SIC server with 100 or more SEP clients.
For best performance, the network-based SIC server requires a dual-core or better processor. For client loads of less than 100, a single-core processor may provide acceptable performance.
Network-based SIC server placement
The purpose of SIC is to trade a large amount of file I/O (reading an entire file into memory and then scanning it) with a smaller amount of network I/O (passing metadata about a file back and forth between SEP client and the SIC). The fewer differences between the files on the SEP clients sharing the same SIC, and the lower the network latency between the SIC and SEP clients, the bigger the benefit. To ensure the best performance gain from SIC use the following best practices:
- Install the network-based SIC server on the same VDI cluster as its SEP clients
- If the network-based SIC is installed to a physical system, install it to a computer on the same physical network segment as the VDI cluster
- If there are multiple VDI clusters in the environment in different physical network segments, separate cache servers should be used for each network segment/VDI cluster
- Separate cache servers should be installed for each base image to maximize content overlap between systems
Network-based SIC server client load
The network-based SIC Server can support up to 1,500 concurrently scanning SEP clients. For a network-based SIC server to support more than 1500 clients, scan randomization must be enabled on clients utilizing SIC. Using scan randomization, the cache server can support 1500 clients per hour of the randomization window up to a maximum of 24,000 clients.
SEPM Policy considerations
Only one network-based SIC server IP address or hostname can be configured for each SEP Virus and Spyware Protection policy. It may be necessary to split Client Groups up based on SIC size limitations in large VDI infrastructures. Alternatively, a DNS alias (A record) can be created to allow DNS round-robin between several network-based SIC servers.