Introduction

In order to better utilize the bandwidth between the Management Server and the clients, a Distribution Server (DS) can be used to store both software packages and redistributable files ( the \ComputerJobs, \UserJobs and \Redist folders of the Management Server). This is especially useful in locations where the connection to the Management Server is limited/has a lower bandwidth than client computers on a direct LAN connection to the Management Server.

The Distribution Server ensures that each file requested is only drawn/downloaded from the Management Server once. From the Distribution Server, the files are then redistributed to clients, thus preserving the bandwidth and load on the Management Server. Depending on the configuration of the Distribution Server, changed/updated files on the FE are automatically updated on the DS. This ensures that clients are not using files that are no longer equal to the files being served by the FE(essentially out-of-date), avoiding the installation of packages that have been reconfigured/changed/updated.

The BAADS does not hold a 1:1 representation of the files/folders located in the 'Container' on the Management Server, it rather organizes the files in a flat-file structure ordered by the MD5 checksum of the content of the files. This is done both to secure correct file transfers and to exploit the fact that most files in multiple Management points are equal once they have been promoted from dev/test/prod. This means that a package on, say the Dev point that has been promoted to the Prod point contains files with matching MD5 checksums. Since the BAADS organizes files based on the MD5, the two files are only stored once on the BAADS.

Clients that are requesting a software package receives the MD5 checksum for that file from the FE. The BA is then using this checksum to locate a file with that checksum in its own file cache. If it is not found there, it will search for the checksum among the peer BA's that it is connected to. Eventually, if the client is connected to a DS, it will then request the file there. If the client is not connected to a DS, it will download the file directly from the FE.

DS modes

The BAADS can be configured in three different modes:

Fetch

Fetch mode is the simple 'deploy-and-forget' approach. When a BA requests a file, the file can either be present on the DS or not be present. If present, it will be served to the BA, if not, it will first be downloaded from the FE and then served to the BA. The DS can keep track of multiple BA's requesting the same file simultaneously, thus avoid downloading the same file in two similar requests at once. When a client (BA) requests a file that has been changed on the Management Server, it also means that the file being requested has a changed MD5 checksum. Therefore, the new/updated file is downloaded (fetched) from the FE dynamically.

FetchAndPreload (default)

FetchAndPreload mode acts in the same way that the Fetch mode does, except that it can also preload the redistributable files (\Redist) and packages (\ComputerJobs and \UserJobs) from the Management Server. This also replaces the functionality of the Synchronization Service (CiSync).  The Preload can be done in three ways;

1. By applying a preload-schedule that will update the DS on a regular basis, i.e. every night between 02.00 and 04.00
2. On-demand (Update now) as an action on a specific DS in the System plugin of the CapaInstaller console.
3. On-demand (Update now) as an action on a specific software package in the Configuration Management plugin of the CapaInstaller console.

Preload

The Preload mode supplies the preload functionality described in the FetchAndPreload mode (above) but will NOT fetch new files on demand when/if a file has been updated on the Management Server. This model exists in order to comply with strict bandwidth restrictions between geographical locations where heavy use of bandwidth over WAN is prohibited. This mode also resembles that of the old CiSync approach except that when a new/updated file that does not reside on the DS is requested, the DS denies the file request from the BA. This will result in the software package changing from 'Installing' to 'Cancelled', meaning that the client will retry the package installation on the next agent run until a preload has been completed or the requested file is made available on a nearby peer (BA).

File cleanup

In contrast to the Synchronization Service (CiSync), the BAADS does not directly clean up old files that have been deemed unnecessary on the FE because it was replaced by an updated file or because the software package was deleted. Instead, it stops using the file, simply because the clients will stop requesting it (the FE will no longer return the old MD5 checksum). As a result, the file cache on the DS will grow at a steady pace as new(er) files are being downloaded from the FE. However, the DS will automatically limit the number of files in the cache to comply with the DS configuration that sets a limit for both the maximum size of the cache and the minimum free disk space on the disk that holds the cache. The cleanup procedure will preserve files being requested often in favor of more seldom-used files. Both limits can be set as fixed sizes (in GB) or as a percentage of the total size of the disk, i.e. 200 GB or 30%.

Max Requesters

The DS also has a limit of the maximum clients that can request the same file concurrently. This means that if a client requests a file from the DS, and the DS fetches the file while similar requests (on that file) arrives, they are being queued on the same file job. When/if there are more requesters to that particular file, they are still getting progress information on the file transfer from the FE to the DS but then, on completion, being requested to pause (for a fixed period) and to then restart the discovery process in order to gain access to the file from one of the peers that were among the first requesters. This will preserve the utilization of the DS by making use of the peering BA's.