Guidelines for installing and running the Symantec Endpoint Protection Manager (SEPM) in a VMware image.

Article:TECH132456  |  Created: 2010-01-14  |  Updated: 2014-01-22  |  Article URL http://www.symantec.com/docs/TECH132456
Article Type
Technical Solution


Issue



You would like to know how to install the Symantec Endpoint Protection Manager (SEPM) to a VMware image or wedge, and need recommendations for memory, CPU and hard drive performance settings.

 


Solution



 

The Symantec Endpoint Protection Manager is very I/O intensive and subject to random spikes of heavy resource usages in dealing with clients, HTTP traffic and disk I/O transactions. As a result, a minimally designed VMware may suffer performance issues and “fall behind” in logs, requests for content / policies and definitions. With this in mind, Symantec STRONGLY recommends the following settings as a “functional minimum” set of system requirements:

  • The VMware image should be static in its MAC address and its IP address
  • The VMware image should not be compressed or use compression in the hosted OS
  • The VMware image should have access to a full Gigabit network interface card
  • The Vmware image should not be subject to vmware live migration

The VMware image should have the resources tab set as follows for a minimal small environment (1-5000 endpoints)

  • 2 CPU cores minimum at all times
  • The cores should be set to a minimum speed of 2GHz and a maximum of infinity
  • Memory allocation should be set to 4 GB minimum at all times for the SEPM alone. Count the SQL server separately.
  • The SQL database should not reside in the same ESX cluster for better I/O handling
  • Drive space for the image should be 150 GB based on content retention policies

For lager environments or transactionaly noisier environments you may need to increase the "Minimum" settings above significantly.  This will help to ensure the Symantec Endpoint Manger does not fall behind in log processing and definitions processing leading to the Symantec Manager 'stalling' and or not being able to be logged into locally or by the Remote Management interface.

Since every VM\hyper-v drive cluster and hardware cluster varies along with work load types Symantec cannot explicitly predict or define a "Hardware level" that may be sufficient for you or your environment.  With that in mind Symantec would STRONGLY suggest over-engineering the virtual devices and then trimming down individual facets until a performance and reliably balance can be meet.

A good example baseline may be as follows for a medium deployment. (5000-10000 clients)
4 dedicated cpu cores with a 2ghz minimum speed
8 gigabytes of ram + 8 gigabytes of pagefile space
300 gigabytes of disk storage for the SEPM manager alone.

If the listed specs do not sufficiently keep up with high demand or load situations you would then tune the vmware to have more resources.   Increasing the system RAM first,  then increasing the cpu core count second.

 If you find that even with large amounts of CPU cores (8 or more) and large amounts of RAM (16 gigs or more) the Sepm Manager is not able to keep up with sustained load,  you may need to increase the availability of more Disk I/o operations per second to resolve this or see if there is another application on the system or the Raid cluster\lun that is consuming to many IOP/s to allow the SEPM to work properly. 


Extra considerations for the SEPM SQL database:

Several tables within the database that SEPM uses are, by default, capable of auto-growing to prevent stalling the publishing of definitions. Allow the SEPM to install and create the database if your security policies permit. If your security policies do not allow for automatic database creation by third party applications, manual database creation is another option for automatic table growth.


Other considerations, reducing load to extend reliability: With the SEPM being a heavy I/O and memory intensive application to host in VMware, there are other things that you can do to help improve reliability under extended high load situations (such as a virus outbreak, mass migration). 

  1. Contact your support team at Symantec and discuss what log types (from clients) and reports you actually need to store in the database. Reducing the amount of things stored in the database will reduce traffic to the VMware image, reducing the total I/O load and allowing the SEPM to be more responsive in a extended high load situation.
     
  2. Reduce data retention times. Reducing the data retention time of logs, reports and content can also help with reducing the overall size of the database, and will likely increase the response time to generate a report in the interface.
     
  3. Evaluate and better manage the definition revision count. Review with your Symantec support team the number of definition revisions you are keeping. By properly setting the definition count and retention you can better manage the amount and flow of definitions from your SEPM. By setting to a low value, you can have situations where clients are requesting full updates when a micro update could be possible, and keeping too many may consume large amounts of space on the IIS directory structure and in the SEPM database (SQL).
     
  4. Set up Group Update Providers (GUP). By setting up group update providers you will have the second most significant impact on SEPM performance in a VMware. Instead of having all clients update from their respective manager, have a GUP update from the SEPM, then have the remaining clients update from the GUP. This will dramatically reduce the amount of I/O on the SEPM, reduce load from SEPM to SQL, and reduce the load from Client to SEPM and reduce HTTP traffic to the SEPM. With this setup, the I/O and HTTP traffic load of updating definitions can be spread to a larger base and enhance SEPM performance and longevity in a VMware environment.
     
  5. Set up an internal LiveUpdate server. Similar but not the same as a GUP, a LiveUpdate Administrator 2.x (LUA 2.x) can be used to update clients instead of the clients updating from the SEPM. Again this will reduce the HTTP traffic to the SEPM to check in for updated definitions and reduce the I/O of the SEPM having to create definitions and store them. Additionally it will reduce the traffic from the SEPM to the SQL database to mirror the definitions, and reduce the size of the SQL database as well. 
     
  6. Isolate high-I/O processes. For processes that use large amounts of I/O resources such as: SEPM database backup, Reporting, and Notification, consider using a VM on a separate physical computer. For Reporting and Notification, set the server as the first server in Site properties so that clients requesting processing are not affected by notification tasks.
  7. Lower the priority of replication servers in management server lists. By doing this, replication servers can process fewer client requests and focus on replication. If a site only has a few servers, the LiveUpdate, backup, reporting, notification, and replication Servers can share the same VM image server.
     

These steps will help ensure optimal SEPM performance within a virtual environment. While not as responsive as a true hardware device, this will help to keep the SEPM healthy in long term virtual usage.  Please be aware, with the SEPM being I/O intensive, it is important to also consider the I/O needs of other VM systems (such as mail servers or database servers) upon the host OS since installing them with the SEPM can result in I/O bottlenecks occurring in either drive channels or networking. 

 




Legacy ID



2010051409055348


Article URL http://www.symantec.com/docs/TECH132456


Terms of use for this information are found in Legal Notices