A relay is an agent that is configured to redistribute software
and security updates to other agents. Relays help your deployment perform
well as it grows and scales.
The following information is only applicable to relay update functionality for
versions earlier than 20.0.0-3445. See also Improvements to the
relay.
Relays are organized into relay groups. The relays provided by Server & Workload Protection 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 is 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
If you need to reduce bandwidth and costs on your Internet or WAN connection, deploy
a relay inside your own network. This reduces how much external traffic occurs when
protected computers need to download updates. 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 more
relays.
Improvements to the relay
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 Server & Workload Protection, 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 Server & Workload Protection relays.
Note
These relay improvements are currently in preview and only available to
specific customers. For more information about accessing the latest relay
improvements, contact Trend Micro Support.
When you deploy a new relay or upgrade an existing relay to version 20.0.0-3445 or
later and you have opted into the relay improvements preview, as per the preceding
note, 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 cannot be arranged in a hierarchy. If you have older relays arranged
in a hierarchy and upgrade them to agent version 20.0.0-3445 or later, those
relays will each get their updates directly from the relays provided by the Server & Workload Protection service.
When you enable the enable-edge-relay feature flag and then
navigate to Administration → System Settings → Updates → Security Updates → Secondary Source, you will notice a new option Allow Agents/Appliances to
download security and software updates from Primary Tenant Relay Group if
user-deployed relays are not accessible. By default, this option is
disabled and does not affect any of your previous settings. However, once
enabled, it will allow you to download security and software updates from
Primary Tenant Relay Group and help resolve any issues arising from relays
deployed by you.
Information about older relays
The following information is only applicable 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 Server & Workload Protection and the Primary
Security Update Source (usually via their Internet or 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, as opposed to 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 that can
specify the following:
Update order—Child relay sub-groups download from their parent
group, which must finish its own download first. Therefore a chain of sub-groups
can be useful if you want a delay, so that all updates are not 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, while
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). For more information, see Server & Workload Protection Sizing.
Hierarchies are set up during relay group creation.
Table of Contents
The page you're looking for can't be found or is under maintenance
