Resource usage of Deploy Jobs
This topic describes the following file and package deploy jobs and their resource usage:
File Deploy Jobs
A File Deploy Job arranges to deploy a file from any NSH-accessible location to one or more remote targets. A File Deploy Job operates by first constructing and then executing an NSH script to copy (push) the requested file. This script runs on the Application Server. The action of the script depends on the type of File Deploy Job:
- Direct File Deploy Job — The script running on the Application Server copies the file from its source to each target. The Application Server acts as an intermediary, and there is no direct data transfer between the source and the target.
- Indirect File Deploy Job — The script running on the Application Server copies the file to one or more remote repeaters. The Application Server again acts as an intermediary. A script then runs on each repeater to push the file to the final target.
If you specify pre-commands or post-commands as part of a File Deploy Job, these commands are executed on the remote target.
The following table shows a summary of resource usage by File Deploy Jobs.
The server from which the files are deployed might experience heavy load during a File Deploy Job. Similarly, any repeaters involved might experience heavy load during a File Deploy Job.
BLPackage Deploy Jobs
A BLPackage is an aggregation of many types of server objects, including, for example, registry keys and configurations within files, not just files. These server objects are packaged together for unattended deployment on multiple remote hosts.
BLPackage Deploy Jobs consist of a sequence of work items run in the following phases:
The Staging phase has the potential to generate significant workloads on the file server (or other server that is providing the package source files). In contrast, the Commit phase presents almost no load to the BMC Server Automation infrastructure because most of the work for this phase is carried out on the target hosts.
With the exception of work items for predeploy and postdeploy commands, work items for the BLPackage Deploy Job's Commit phase are implemented as lightweight work items. For information, see Lightweight work items.
In BMC Server Automation version 8.1 and later, several phase work items have been enhanced to use asynchronous BLExec tasks for execution. This enhancement allows for increased throughput, even without populating the thread pool for lightweight work items. For information about asynchronous BLExec tasks, see Asynchronous Blexec tasks.
The following table shows a summary of resource usage by BLPackage Deploy Jobs.
The Staging phase has the potential to generate significant workloads on the file server (or other server that is providing the package source files. In contrast, the Commit phase presents almost no load to the BMC Server Automation infrastructure, because most of the work for this phase is carried out on the target hosts.