Smarter by Design.Simpler for Business
Load Balancer - ADC
Load Balancer - ADC is TR7's application delivery engine that receives traffic at a single point and intelligently distributes it to the target servers behind it. Every incoming request is first received by a vService (listener); it passes through a chain made up of TLS termination, conditions and actions (if WAF - WAAP or AGS - AAM is enabled on the vService, security inspection also takes place in this chain); it is then forwarded, according to the selected distribution algorithm, only to a healthy Backend Service or Backend Group.
In this way, load balancing moves beyond a router that distributes traffic blindly and becomes a delivery layer that understands requests, passes them through security inspection, shapes them according to conditions and continuously monitors the health of targets. It eliminates the single point of failure, makes maintenance uninterrupted and makes application traffic inspectable end to end.
Local delivery layer
Load Balancing is the local layer that distributes traffic to servers within a data center. Routing between data centers and geographic routing is performed by GTM (Global Traffic Manager), a separate product, at DNS time, before a connection is even established. When the two products are used together, they complement each other.
TR7 Product
Load Balancer - ADC is TR7 ADC (Application Delivery Controller), one of TR7's four separately licensed products. Products are licensed individually or in bundles; licensing details are available on tr7.com.
TR7 products: Load Balancer - ADC · WAF - WAAP · AGS - AAM · GTM (Global Traffic Manager)
3
vService types
HTTP (L7) · L7 TCP · Network; a dedicated listener for each protocol
40+
Condition types
"When": request, source, security and traffic criteria
36+
Action types
"What to do": redirection, header, limit, block, quarantine
10
Profile types
Health check · compression · cache · timeout · log · report
Failover
Health-aware
An unhealthy target is automatically removed from rotation once the failure threshold is exceeded
Live
End-to-end monitoring
Dashboard, 9 log sources, live statistics and reports
Ease of Use
No code / scripts
All configuration from the web interface; no programming knowledge required
What Is Load Balancer - ADC?
Instead of piling incoming network traffic onto a single server, Load Balancer distributes it evenly across multiple servers that provide the same service; this application delivery technique is called load balancing. The goal is to remove the capacity and availability limit of a single server.
In a single-server setup, that server slows down under load, and when it crashes the service stops entirely. Load balancing solves this risk by receiving traffic through a single virtual address placed in front and sharing it among the real servers behind it. Clients connect only to this single address; they do not know how many servers are behind it or which one they are directed to. Even when a server is added or removed, the address the client connects to does not change.
This distribution is not random. The load balancer continuously monitors the health of each server and sends traffic only to servers that can respond; it automatically removes a server that goes out of service from distribution and takes it back when it recovers. Which server is selected is determined by a distribution algorithm (in turn, to the one with the fewest connections, weighted by capacity, etc.). In this way, load balancing provides three core benefits:
- High availability: even if a server goes down, the service continues uninterrupted with the servers that remain up.
- Scalability: capacity is increased by adding new servers.
- Performance: since the load is distributed evenly, no single server becomes a bottleneck on its own.
Load balancers can operate at two different layers. L4 (connection layer) balancing forwards packets quickly by looking only at the IP address and port; it does not see the content of the request. L7 (application layer) balancing also parses the content of the request: it can route based on information such as the HTTP header, path and cookie, and it can terminate TLS encryption and apply security inspection. A modern load balancer is therefore not only a traffic distributor; it is also a security and application delivery layer.
For this reason, load balancing is not exclusive to setups with multiple servers; its use is recommended even in environments with a single server. Even in single-server setups, the load balancer adds value as an inspection and delivery layer positioned in front of the server behind it, without exposing that server directly to the internet:
- Security in front: TLS termination and security inspections (WAF - WAAP and AGS - AAM, if enabled on the vService) filter requests before they reach the server; the real server is closed to direct access.
- Single, stable entry point: clients connect to a fixed address; even if the address, certificate or maintenance of the server behind it changes, this address does not change.
- Health and uninterrupted maintenance: when the server is taken into maintenance, traffic is directed to a backup address or a maintenance page; problems are seen early with health checks.
- Content and performance control: functions such as compression, cache, header editing and conditional routing are applied on a single server as well.
- Visibility: all traffic can be logged and monitored; the server's behavior is observed through live sessions and reports.
- Future readiness: when a second server is added later, scaling becomes as simple as defining a new target on the load balancer without disrupting the existing setup.
Load Balancing in TR7
TR7 provides all of the core functions above and adds an intelligent decision layer on top. A classic router forwards incoming traffic in a fixed way; it does not take into account the health of the target server, the content of the request or its security status. TR7 load balancing makes this behavior intelligent: before delivering each request to the target, it inspects, classifies and shapes it, and then distributes it to the most suitable one among only the healthy targets.
At the center of the structure is the vService. A vService listens for traffic on an IP address and port; it is TR7's counterpart of the concept known in the industry as a virtual server / listener. Each vService determines which target (Backend Service or Group) it is directed to and which security layers (WAF/AGS), certificates and profiles (compression, cache, log…) are applied. When a request arrives, the vService evaluates the conditions, applies the matching actions and determines the target with the selected algorithm.
All configuration, from listeners to health checks and from conditions to profiles, is done entirely through the web interface without requiring programming knowledge. The Manual Condition and Manual Action types, which allow the engine configuration line to be written directly, are for advanced use only.
Difference from GTM
Load balancing and GTM, which works at the global DNS layer, make decisions at different layers and at different moments; when used together, they complement each other:
| Load Balancing (vService) | GTM | |
|---|---|---|
| Scope | Within a data center | Between data centers / geographic |
| Layer | Connection and application (L4–L7) | DNS (name resolution) |
| Decision moment | After the connection is established | Before the connection is established (in the DNS query) |
| Target | Load distribution between servers | Routing between data centers / regions |
Why Is It Needed?
Structures based on a single server and static routing fall short as traffic and continuity requirements grow. Load balancing responds directly to each of these limits:
| Challenge | Solution with load balancing |
|---|---|
| Single server = single point of failure | Traffic is distributed among multiple healthy Backend Services; when one goes down, the others take over. |
| Traffic going to an unhealthy server | The health check automatically removes from rotation a target that exceeds the consecutive failed attempt threshold; it takes the target back when it recovers. |
| Uninterrupted maintenance / update | With maintenance mode, a Backend Service or an entire group is taken out of traffic and put back into service when maintenance ends. |
| Servers with different capacities | With weight and connection limit, more traffic goes to the stronger server and less to the weaker one. |
| Raw, uninspected traffic | With conditions and actions (and WAF - WAAP and AGS - AAM, if enabled), the request is validated, shaped and blocked when necessary. |
| TLS load and certificate management | TLS termination is carried out centrally on the vService; if required, traffic is re-encrypted and forwarded to the server with the Backend Service's SSL Service setting. |
| Sudden traffic spikes | Capacity is grown elastically by adding new Backend Services; servers are protected from overload with connection limits. |
| Applications that require session consistency | With Persistence, connections from the same client are always directed to the same target; session integrity is preserved. |
| Abuse (DDoS, bot, brute-force) | With rate limiting, quarantine and Advanced Traffic Inspection, abnormal traffic is monitored, limited or blocked. |
| Slow response and bandwidth cost | With cache and compression profiles, performance increases and the load on the Backend Service decreases. |
| Need for content-based routing | With L7 conditions such as path, header and cookie, the same address is routed to different application or server groups. |
| Real servers being directly exposed | Clients connect only to the vService; the addresses of the Backend Services remain hidden from the outside world. |
| Poor user experience during errors | On Backend Service or load balancer errors, custom content display or redirection actions take effect. |
| Lack of visibility | Traffic is monitored end to end with the Dashboard, log sources, live sessions and reports. |
How Does It Work?
In HTTP and L7 TCP vServices, a request passing through the TR7 load balancer goes through the chain below; each stage carries the request to the next step in a more refined form:
01 · ListenervService receivesThe request is received by the vService listening on IP:port
02 · TLSEncryption is terminatedTLS termination is performed; the content becomes inspectable
03 · SecuritySecurity inspectionIf WAF - WAAP or AGS - AAM is enabled on the vService, the request passes through application security and identity/access inspection
04 · Condition & ActionThe request is shapedActions bound to matching conditions are applied (redirect, header, limit…)
05 · AlgorithmThe target is selectedConditional Backend Service selection and persistence are evaluated; otherwise, one of the healthy targets is determined with the distribution algorithm
06 · DeliveryForwarded to the Backend ServiceThe request is forwarded to the selected Backend Service or Group; the response returns to the client
Throughout this chain, the Health Check runs continuously in the background: a target that exceeds the consecutive failed attempt threshold in the profile is removed from rotation, and when it reaches the consecutive successful attempt threshold it is automatically taken back into traffic. In this way, the distribution decision is made according to the current health status of the targets.
Network vServices run on a separate L3/L4 data plane; in this type, request content is not parsed, and the TLS, WAF/AGS and L7 condition-action stages are not applied.
Core Building Blocks
The operating structure of load balancing consists of several interconnected components. Together, the layers below produce the "inspecting, shaping and health-aware distributing" delivery behavior:
vService Entry point
Receives and listens for traffic on an IP:port. Determines its target (Backend Service/Group), security layers and profiles. It comes in three types: HTTP (L7), L7 TCP and Network.
Backend Service Single target
A single target server that traffic reaches (address:port). It can be any service such as web, application, database or email. Weight, connection limit, health check, SSL and maintenance mode are defined separately for each.
Backend Group Collective management
Brings together multiple servers that provide the same service under a single logical structure. Settings such as health check, SSL and maintenance are defined once at the group level; values such as each server's weight/limit remain individual. It is a building block independent of the Backend Service.
Conditions & Actions Decision and intervention
Conditions define the "when" (the request's attributes, its source, security status, traffic density); Actions apply the "what to do" (redirect, add/modify header, rate limit, block, quarantine). An action bound to a condition shapes traffic declaratively.
Profiles Reusable settings
Packages in which settings such as health check, compression, cache, timeout, log, notification and report are defined once and assigned to many places. When a profile is changed, all vServices, Backend Services and Groups that use it use the same setting. TLS security profiles, on the other hand, are managed under Certificates & PKI.
Health Check Continuity assurance
Periodically measures the status of Backend Services (TCP, HTTP(S), Ping, etc.). Automatically removes a target that exceeds the failure threshold from rotation and takes it back when it recovers. Targets without an assigned health check always continue to receive traffic.
vService Types
Each vService is defined with one of three types according to the protocol of the traffic it listens to. The type determines the available conditions, actions, algorithms and TLS behavior:
| Type | Layer | Use | Highlights |
|---|---|---|---|
| HTTP (L7) | Application (L7) | Web applications, APIs, HTTP(S) services | Full L7 visibility: header, path, body conditions; WAF/AGS; content/header actions |
| L7 TCP | Application (L7 TCP) | TLS/TCP-based services (e.g. databases, custom protocols) | SNI/SSL conditions, TLS termination or passthrough, RDP Cookie algorithm |
| Network | Network and connection (L3/L4) | High-performance, protocol-independent L3/L4 traffic | DSR/Route/SNAT modes, port range, low-latency fast distribution |
Monitoring and Observability
Load balancing does not only distribute traffic; it makes the behavior of each vService monitorable live and retrospectively. A management screen dedicated to each vService opens from the Left Monitor Panel. The Logs & Tracking tab is displayed if the vService produces at least one record source, and the Report tab is displayed if a Reports profile is assigned to the vService:
Dashboard Time range and trend
A multi-panel view of the vService's traffic, connection, health and error metrics over the selected time range.
Load Balancer Management What is configured?
The management canvas in which the entire configuration of the vService is summarized in sentences; each section leads to editing the related setting.
Logs & Tracking 9 sources
Debug, HTTP and TCP logs; vService Sessions (live sessions); Advanced Traffic Inspection, Quarantine and Advanced Captcha tracking/quarantine tables.
Live Stats Real time
A live view of the vService's instantaneous traffic and connection counters, refreshed once per second.
Report Historical trend
An HTML, PDF or XLSX report containing the traffic breakdowns of the selected period (country, page, response code, browser, Backend Service, TLS).
Key Features
Three vService typesEvery traffic type from L4 to L7 with HTTP (L7), L7 TCP and Network.
Health-aware distributionA target that exceeds the failure threshold is automatically removed from rotation; it is taken back when it recovers.
Distribution algorithmsRound Robin, least connections, weighted, hash and protocol-specific methods.
40+ condition typesMatching based on request, source, security and traffic criteria.
36+ action typesRedirection, header management, rate limit, block, quarantine and content replacement.
TLS termination & re-encryptCentralized certificate management on the vService; re-encryption between TR7 ↔ Backend Service with the SSL Service setting on the Backend Service.
Working with WAF - WAAP and AGS - AAMWhen licensed, the WAF - WAAP and AGS - AAM products are enabled on the same vService.
Persistence (session continuity)Cookie/hash-based methods for directing the client to the same target.
Profile-based configurationDefined once, assigned to many places: health, compression, cache, timeout, log, report.
Uninterrupted maintenanceWith maintenance mode, Backend Services or groups are taken out of traffic and put back into service after maintenance.
End-to-end monitoringDashboard, 9 log sources, live statistics and historical reports.
Ease of use (no code required)Everything from the web interface; no programming knowledge required.
Use Cases
Web Application / API Publishing HTTP (L7)
A web application or API is published with high availability by distributing it across multiple servers; WAF, TLS and content actions are applied on the vService.
Scalable Server Group Management Backend Group
Dozens of servers are brought together under a single Group; health, SSL and maintenance settings are defined once at the group level. Servers are added as traffic grows and removed as it decreases.
Secure Traffic Delivery Condition · Action · WAF
Requests are classified with conditions; abuse is blocked with rate limit, block or quarantine actions; the application layer is protected with WAF/AGS.
High-Performance L4 Distribution Network vService
Protocol-independent, low-latency traffic (e.g. high-volume TCP/UDP) is distributed quickly at L4 level with DSR/Route/SNAT modes.
Uninterrupted Maintenance & Version Migration Maintenance mode
Backend Services are updated while traffic is shifted to the other servers by putting them into maintenance mode; version migrations are carried out without interruption by starting weight and connection limits low and increasing them gradually.
Object Model
TR7's load balancing building blocks correspond to the layered load balancing model widely used in the industry; only the naming is specific to TR7:
| TR7 object | What it is | Industry equivalent |
|---|---|---|
| vService | The central object that listens for traffic on an IP:port | virtual server / listener |
| Backend Service | A single target server (address:port) | node / real server |
| Backend Group | An independent structure that brings together servers providing the same service | server group |
| Health Check | The check that periodically measures the health of Backend Services | monitor / health monitor |
| Persistence | Session continuity that always directs a client's connections to the same target | persistence / session affinity |
| Condition + Action | Declarative definition of "if X, do Y" | policy |
| Profile | Reusable settings package (health, compression, cache…) | profile |
Terminology
| Term | Description |
|---|---|
| vService | Receives and listens for traffic on an IP:port; determines its target, security layers and profiles. |
| Backend Service | A single target server that traffic reaches (address:port). Referred to as "Backend Service" in running text. |
| Backend Group | A structure independent of the Backend Service that manages multiple servers providing the same service with common settings. |
| Condition | The "when" criterion in which the request/source/security status is evaluated. |
| Action | The "what to do" intervention applied when a condition matches. |
| Profile | A reusable settings package defined once and assigned to many vServices and Groups. |
| Health Check | A periodic check that measures the status of Backend Services; removes an unhealthy target from rotation. |
| Persistence | Session continuity that ensures a client's connections are directed to the same target. |
| SNAT (Source NAT) | Ensures that the source IP address of the request forwarded to the Backend Service is replaced with the IP address of the TR7 device. In this way, the Backend Service's response traffic returns through TR7 and the traffic flow is maintained symmetrically. The Use Client IP option in the Backend Service's SNAT field, on the other hand, preserves the client's real IP address. |
| TLS Termination / Re-encrypt | Decrypting the encryption on the vService and, if necessary, re-encrypting it and forwarding it to the Backend Service. |
Sections
Monitoring and Management
Traffic and Targets
vService
The listener that receives traffic; HTTP (L7), L7 TCP and Network types.
→
Backend Services
Definition of the single target server that traffic reaches (address, port, weight, health, SSL); with Dashboard and Health Checks records.
→
Backend Groups
An independent structure that brings together servers providing the same service with common settings; with the group Dashboard.
→
Traffic Decision and Intervention
Conditions
40+ condition types that evaluate the request: source IP, header, path, SSL, WAF, traffic density…
→
Actions
36+ actions applied when the condition is met: redirection, header, limit, block, quarantine.
→
Configuration
Typical Setup Flow
A load balancing structure is usually set up in the following order:
1
Step 1 Target servers are defined
Servers that traffic will reach are added as Backend Services; multiple servers providing the same service are added as a Backend Group.
2
Step 2 The organization certificate is added
For HTTPS publishing and TLS termination, the organization's TLS certificate (and the intermediate/root certificate chain, if any) is added to TR7 through SSL/TLS Certificates. This certificate is assigned to the vService in a later step.
3
Step 3 Health check is assigned
To monitor the status of targets, a Health Checks profile is defined and assigned to the Backend Service/Group.
4
Step 4 vService is created
The vService that will receive traffic is added; its type (HTTP (L7) / L7 TCP / Network), listener IP:port and target are determined.
5
Step 5 Security and profiles are applied
TLS termination is enabled with the added organization certificate; if necessary, WAF/AGS and profiles (compression, cache, log, timeout) are assigned to the vService.
6
Step 6 Conditions and actions are defined
To classify and shape traffic, conditions and the actions bound to them are added.
7
Step 7 Traffic is routed and monitored
Traffic is routed to the vService's listener address; health and traffic are continuously monitored from the Load Balancer vServices screens.
