Sizing for distributed repositories depends on the network architecture of the environment.
Distributed repository sizing recommendations:
Server class hardware or equivalent VM, 2–4 CPU
Gigabit or greater network interface
100-GB disk free space
Up to 5,000 systems with high latency connections
Up to 20,000 systems with low latency connections
Tip
When configuring updates, randomize update times across endpoints. Peer-to-peer enabled agents can increase distributed repository system capability by 10–100X, enabling endpoints to share repository files within the network segment.
Example 1: Endpoints concentrated in a single low-latency data center
Fewer than 5,000 endpoints, updating can be done directly from the ePO - On-prem server or Agent Handlers. After the first 5,000 endpoints, start adding a distributed repository for every 20,000 systems.
Actual endpoint count per repository is a factor of client update speed versus concurrent repository connections versus network interface usage.
Tip
Peer-to-peer updating significantly reduces network usage and concurrent connections experienced by the distributed repository, allowing more endpoints per repository.
Example 2: Endpoints concentrated in high-latency data centers
With geographically distant data centers, to reduce WAN bandwidth, place distributed repositories in each zone where high concentrations of endpoints exist. Use the same calculation of one repository for every 20,000 systems.
Example 3: Endpoints concentrated in branch offices with fewer than 1,000 endpoints
Peer-to-peer updating is highly effective in this environment. With peer-to-peer enabled, choose a single SuperAgent distributed repository or no repository at all (preferred). If a local distributed repository is not available, only the initial catalog downloads and peer-to-peer traffic cross the WAN to download from a remote distributed repository.
For information about creating and using SuperAgent repositories, see the product guide for ePO - On-prem.
Example 4: Home office or endpoints directly connected to the Internet
For small endpoint counts, updating can occur using an Agent Handler in a DMZ. For environments where more than 5,000 systems connect to the DMZ, add distributed repositories. These systems typically use connections that are geographically distant. The total concurrent connection load on the distributed repositories is high so the scale factor is lower.
Start with 5,000 systems per distributed repository. Peer-to-peer updating is ineffective because the endpoint's subnet likely has few endpoints (if any) to share content with.