When does your system need to grow?

Deployment and Installation Center | Data Security Solutions | Version 7.7.x

There are numerous triggers that might prompt your system expansion. Among them:

You may or may not be aware of performance issues affecting your system. If you are experiencing slow discovery or fingerprinting scans, for example, this could be an indication of an overworked crawler. You may benefit from an additional crawler or Data Security server. If user are experiencing slow Web or email transactions, you may benefit from an additional policy engine. Even if you are not aware of performance issues, your system resources may not be fully optimized.

To see how your system is performing, open TRITON - Data Security and select Main > Status > System Health. You can expand each module and view statistics on the load, the number of transactions, the latency, and more.

Before adding modules, try balancing the load between your existing Data Security servers (policy engines). To do this, go to Settings > Deployment > System Modules, and click Load Balancing. Select a service and indicate which policy engine you'd like to assign to that service.


	Note Websense recommends that you do not distribute the load to the TRITON Management Server.

The number of users grows

In a typical small organization (1-500 users), you might only need a TRITON Management Server and a protector to monitor traffic. A larger organization (500-2,500 users) might have a TRITON Management Server, a supplemental Data Security server, and a protector, with load balancing between the protector and supplemental server. (You cannot balance the load with the management server.)

As your number of users grows, so does your need for a Data Security server.

The number of transactions grows

This is the most important requirement for determining your Data Security needs. Typically the number of transactions grows as your number of users grows.

In monitoring mode, Websense recommends having 1 protector per 20,000 users. This calculation assumes:

The protector is monitoring HTTP and SMTP

There are 9 busy hours per day

There are approximately 20 million transactions per day with a ratio of 15:1 HTTP:SMTP. (HTTP includes GETs and POSTs.)

For more users, add an extra Data Security server and balance the load between the protector and the extra server.

In blocking mode, Websense recommends 1 TRITON Management Server, 1 SMTP agent, and 1 V-Series appliance with Websense Content Gateway software. This calculation assumes:

There are 9 busy hours per day

There are approximately 15 million transactions per day with a ratio of 15:1 HTTP:SMTP. (HTTP includes GETs and POSTs.)

For more users, add an extra Data Security server.

Note that your transaction volume can grow even if your user base does not. If you anticipate adding a significant amount of traffic, you'd benefit from adding one or more Data Security servers.

The number of endpoints grows

If you subscribe to the Data Endpoint and you are adding endpoints to the system, you may need additional servers. A general rule of thumb is to add 1 Data Security server for every 30,000 endpoint clients.

Moving your deployment from monitor to protect

Enforcement requires more resources, particularly because load-balancing must be enforced between policy engines and SMTP agents. If you are moving from monitor to protect, you may benefit from an additional Data Security server.

Moving from a single-site to multi-site configuration

Websense Data Security supports multi-site, distributed deployments. You can have a local policy engine on the protector, for example, and distributed (primary and secondary) fingerprint repositories. You can have a management server in one location and one or more supplemental Data Security servers in other locations.

You can utilize the crawlers on the Data Security servers alone to do your fingerprint and discovery scans, or you can install the crawler agent on additional servers to improve performance. These are just a few of the possibilities, and of course, all are scalable.

See Most common deployments for distributions our customers commonly use.