Topics on this page
How relays work
A relay is an agent that's configured to redistribute both software updates and security updates to other agents, to help your deployment perform well at scale.
Relays are already deployed inside the Workload Security environment, ready for use. To begin using these default relays, simply verify that your computers can connect to the Workload Security listening port number. Under special circumstances, you may need to deploy additional relays in your own environment as detailed in Improvements to the relay.
Alternatively, software updates — but not security updates — can be distributed by a local mirror web server.
How relays distribute updates
This section details relay update functionality for versions earlier than 20.0.0-3445. If you'd like more information about accessing Improvements to the relay added in newer versions, please contact Trend Micro support.
Relays are organized into relay groups. The relays provided by Workload Security are in a relay group named "Primary Tenant Relay Group." If you decide to deploy your own relays, you will need to create at least one more relay group.
Agents get a randomly ordered list of relays for their assigned relay group. When an agent needs to download an update, it tries the first relay. If there's no response, the agent tries the next in the list until it can successfully download the update. Because the list is random for each agent, this distributes load evenly across relays in a group.
When to deploy your own relays
The main reason to deploy your own relays is to reduce WAN bandwidth costs by reducing external update traffic. Deploying your own relays is also useful if you have network segments with limited bandwidth.
For instructions on how to deploy your own relays, see Deploy additional relays.
Improvements to the relay
The following relay improvements are in preview and only available to specific customers at this time. If you'd like more information about accessing the latest relay improvements please contact Trend Micro support.
Major improvements to customer-deployed relays were introduced with agent version 20.0.0-3445. Earlier versions of the relay download every supported agent software package (all versions, all platforms) from Workload Security, and every security update from their primary security update source. This takes approximately 400 GB of disk space and downloads can take several hours to complete. The new relay is a reverse proxy which only downloads and caches agent software packages and security updates that are requested by agents, rather than downloading all released updates. Also, the new relay downloads both agent software packages and security updates directly from Workload Security relays.
When you deploy a new relay or upgrade an existing relay to version 20.0.0-3445+ and you have opted into the relay improvements preview (see note above), you will get the new and improved relay functionality and, if upgrading, will notice an immediate decrease in the amount of disk space required. There are some key differences to be aware of with the new relay functionality:
- New relays can’t be arranged in a hierarchy. If you have older relays arranged in a hierarchy and upgrade them to agent version 20.0.0-3445+, those relays will each get their updates directly from the relays provided by the Workload Security service.
- New relays for agent version 20.0.0-3771 and earlier cannot connect to Workload Security relays via proxy. This support is added in version 20.0.0-3964.
Information about older relays
This section applies only to older relays whose agent version is earlier than 20.0.0-3964.
Relay groups for older agents can be organized in a hierarchy: one or more first-level ("parent") relay groups download updates directly from Workload Security and the Primary Security Update Source (usually via their Internet/WAN connection), and then second-level ("child") relay groups download updates indirectly via the first-level group, and so on. If you put a child relay on each local network, then agent updates usually use the local network connection — not remote connections to the Internet. This saves external connection bandwidth (a typical performance bottleneck) and makes updates faster, especially for large deployments with many networks or data centers.
Performance and bandwidth usage can be affected by relay group hierarchy. Hierarchy can specify:
- Update order — Child relay sub-groups download from their parent group, which must finish its own download first. So a chain of sub-groups can be useful if you want a delay, so that all updates aren't occurring at the exact same time.
- Cost — If large distances or regions are between your parent and child relay groups, it might be cheaper for them to download directly instead of via parent relay groups.
- Speed — If many or low-bandwidth subnets are between your parent and child relay groups, it might be faster for them to download directly or via a grandparent instead of via parent relay groups. However if too many relays do this, it will consume external connection bandwidth and eventually decrease speed.
Your relay group hierarchy could minimize Internet and internal network bandwidth usage. Only one "parent" relay group might use the Internet connection; sub-groups would download from the parent, over their local network connection. Agents would download from their local relay group.
Large scale deployments might have many agents connect to each relay. This requires relays on more powerful, dedicated servers (instead of more relays on shared servers). See Deep Security Agent and Relay sizing.
Hierarchies are set up during relay group creation.