When you consider large or very large Sensor deployments, where the number of Sensors deployed ranges from 36 to 150, there are some important tasks which should be considered before the deployment.
If any user initiates bulk Sensor software deployment requests from the UI in an network environment with large Sensor deployments, it can considerably increase the disk space consumption in the Manager and slow down the deployment process. Inadequate disk space might also result in unpredictable software behavior and operational failures. To prevent such situations and maintain optimal performance, the Manager performs the following while handling bulk software deployment operations:
The Manager reserves 100 GB under required free disk space for Manager operations and considers an additional file size of 1.2 GB to be generated for each software deployment request. When the Manager receives software deployment requests in bulk, it checks the number of Sensors selected and calculates the free disk space required to complete the deployment operation. If there is insufficient free disk space, the following error message is displayed in the UI.
Error message displayed for device software deployment if there is insufficient disk space.png "GUID-C0FF2284-D7E4-4C71-B51D-B75A386CAABF-low.png")
you can also check the deployment status on the User Activities and Background Tasks tabs in Manager → Troubleshooting → Logs page.
Software deployments are critical operations and performed under approved/scheduled maintenance window. If the Manager receives multiple deployment requests in queue along with device software update requests, such as signature file and SSL keys deployments, it prioritizes the software deployment requests ahead of other requests. It also performs disk usage optimization for each deployment to help you perform more deployments at a faster speed, and complete the task within the approved/scheduled maintenance time.
Apart from the above-mentioned actions taken by the Manager for Sensor software deployments, Trellix recommends that you have a good understanding on the best techniques required to accomplish the tasks in your deployment scenario, prior to the deployment. Some of these include the following:
Sensor Software Updates — All Sensor software updates do require a reboot. A reboot can take up to 5 minutes. You can schedule this process even though you can't reboot the Sensor automatically. But any update from the Manager Server causes the process to take place sequentially, one Sensor at a time. You can instead use the TFTP method for updating the Sensor image, which helps you to load concurrent images on the Sensor via the Sensor's CLI at a much faster rate.
For more information, see the Upgrading Sensor software via a TFTP server in the Trellix Intrusion Prevention System Installation Guide.
Central Manager deployment — If you have a large deployment of 200 Sensors, for example, that are deployed across various geographic locations, consider using a Central Manager at your organization's headquarters and deploy a dedicated Manager for each region. Each Manager will then handle the daily device operations for all Sensors configured to it. Note that when you use a Central Manager, your regional/local Managers can add their own region-specific rules, but cannot modify any configuration established by the Central Manager. Configuration updates to the Sensors must be applied through the local Managers. See Installing and Configuring Trellix IPS Central Manager for details.
Usability — Depending on the number of VIDS and Admin Domains defined in your deployment, the Manager Resource Tree can become very crowded which makes it difficult to locate the resource you require at any point of time. It can also lead to confusion if you have not provided unique, recognizable names for your Sensors and any VIDS you create. Note that the resource names appear both in the Resource Tree of the Manager as well as in Alert data and Reports. Your VIDS names should also be clear and easy for everyone maintaining the network to recognize at a glance. For example, compare a worldwide deployment where Sensors are named "4010-1" through "4010-25" as opposed to "UK-London-sens1," "India-Bangalore-sens1," and so on.
Alert Traffic — Take note of the volume of alerting in your Sensors. Depending on the policies deployed on your system, there is potential to starve Manager resources since the resulting alerts are passed to the Manager. As the volume of alerting increases, more data is passed into the Manager. The Manager can handle short bursts of high alert volume, but on an average, the Manager can handle a total of 1500 alerts per minute from all the Sensors configured to it.
Start-up load on the Manager — When the Manager starts, establishing connections with all Sensors can be time-consuming as Sensors continue to collect alerts. If the communication with the Manager is lost, each Sensor must pass its alert data to the Manager when connectivity is re-established. So, it is required to account for the start-up load on the Manager.
Concurrent processes — Be aware of the time periods in which your scheduled processes, such as database backup or report generation, occur, and try not to attempt other tasks during that time period, as this can lead to process locking. This also includes having many users logged into the system simultaneously.