Sophos Database requirements

Hi,

Firstly I would suggest that the database would not grow beyond 1 GB in size and realistically with 2000 clients I would not expect it to grow larger than 300MB over the course of a year.  Alerts older than 12 months are automatically purged but this can be changed to be greater or less and the command line tool purgedb.exe can always be used to supplement this.

The size however really depends on many variables, such as:

1. The policies in use (are you going to use data control, application control, device control, the firewall, etc?).  Not so much from a policy point of view as each unique policy is only stored once but the alerts and events generated by these components.

2. virus outbreaks can also cause the database to grow (especially in the case of a file infector) but this can be cleared.

Ideally the database would be on a separate machine to the management server role.  This would ensure that the management servers services (mainly the RouterNT.exe and Mgntsvc.exe) and SQL service are not competing for the same resources.  This would mainly be memory as both the Router (when managing ~2000+) and SQL can be memory hungry.  To put a number on it 400MB for the Router and 400MB for SQL  The management service less so typically around 120MB.  That being said that is already the best part of a 1GB.  If you do put everything on the same machine, for that many clients I would suggest 4GB as a minimum.

The next question is where to put the distribution point for updating.  If all 2000 machines are on the same LAN and will be updating from a single source, you may want to consider writing the distribution point to a file server/filer for best throughput and not have the clients updating from the distribution point on the management server. Possibly even consider using a web share with IIS\Apache, as I've found this to be more reliable than a UNC file share..  Again this is all ideal setup, 2000 machines on a sensible updating schedule (30 mins?) should be fine updating from the SEC server using UNC.  You could always start off using the local UNC share and monitor it, there is nothing then stopping you adding an additional distribution point on the network the clients could use.  With one updating policy change you could point some or all of them at that.

In terms of performance however, I've found that disk IO on the SQL side of things is probably the best place to put the resource.  So If you can I would suggest you put the database on one of your dedicated SQL servers rather than using the local SQL Express instance that would be installed.  This would both future proof the install and the database would probably be maintained by your SQL DBA then :).

I hope this offers some guidance.

Jak

Hi,

Firstly I would suggest that the database would not grow beyond 1 GB in size and realistically with 2000 clients I would not expect it to grow larger than 300MB over the course of a year.  Alerts older than 12 months are automatically purged but this can be changed to be greater or less and the command line tool purgedb.exe can always be used to supplement this.

The size however really depends on many variables, such as:

1. The policies in use (are you going to use data control, application control, device control, the firewall, etc?).  Not so much from a policy point of view as each unique policy is only stored once but the alerts and events generated by these components.

2. virus outbreaks can also cause the database to grow (especially in the case of a file infector) but this can be cleared.

Ideally the database would be on a separate machine to the management server role.  This would ensure that the management servers services (mainly the RouterNT.exe and Mgntsvc.exe) and SQL service are not competing for the same resources.  This would mainly be memory as both the Router (when managing ~2000+) and SQL can be memory hungry.  To put a number on it 400MB for the Router and 400MB for SQL  The management service less so typically around 120MB.  That being said that is already the best part of a 1GB.  If you do put everything on the same machine, for that many clients I would suggest 4GB as a minimum.

The next question is where to put the distribution point for updating.  If all 2000 machines are on the same LAN and will be updating from a single source, you may want to consider writing the distribution point to a file server/filer for best throughput and not have the clients updating from the distribution point on the management server. Possibly even consider using a web share with IIS\Apache, as I've found this to be more reliable than a UNC file share..  Again this is all ideal setup, 2000 machines on a sensible updating schedule (30 mins?) should be fine updating from the SEC server using UNC.  You could always start off using the local UNC share and monitor it, there is nothing then stopping you adding an additional distribution point on the network the clients could use.  With one updating policy change you could point some or all of them at that.

In terms of performance however, I've found that disk IO on the SQL side of things is probably the best place to put the resource.  So If you can I would suggest you put the database on one of your dedicated SQL servers rather than using the local SQL Express instance that would be installed.  This would both future proof the install and the database would probably be maintained by your SQL DBA then :).

I hope this offers some guidance.

Jak