Can my backends be in a different data center or in the cloud?
Short answer
Yes. Every server that TR7 can reach by IP address or domain name can be a Backend Service; it makes no difference whether the server is in another data center or in the cloud. For this, there must be a route (VPN, leased line, WAN) to that network in the Route Table of the Backend Service. For remote servers, three topics are planned: health check durations according to the WAN latency, encryption on the transmission path with SSL Service, and how the client IP is carried. A remote server is mostly used as a Backup Service; if the two data centers are to serve together, GTM is more suitable.
How Does It Work?
- Address: The IP or domain name (FQDN) of the remote server is written in the Address field of the Backend Service.
- Access: There must be a route to the remote network in the route table of the Backend Service; if there is no route, a static route is defined with Network → Interfaces → Actions → Add Route (Can my backends be on different networks / in different route tables?).
- Domain name: If the address is a domain name, Device DNS must be defined (Can I enter a domain name (FQDN) instead of an IP as the Backend Service address?).
- Traffic: The request goes from the client to TR7 and from TR7 over the WAN to the remote server; the response returns along the same path. Each request experiences the WAN latency once more.
Things to Plan
| Topic | Recommendation |
|---|---|
| Health check | Since the WAN latency is higher than that of the local network, the Timeout and Period values in the Health Checks profile are increased according to the latency (the default value of both is 1 s); otherwise a healthy server may appear as Error. |
| Encryption | For traffic that goes over the WAN, SSL Service is turned on in the Backend Service; if possible, Certificate Verification: Required is selected. |
| Client IP | If the return traffic of the remote server does not pass through TR7, Use Client IP cannot be used; the client IP is carried with X-Forwarded-For or Proxy (Proxy Protocol). |
| Role | If the remote server is to take over when the local servers go down, it is marked as a Backup Service (on HTTP and L7 TCP vServices). |
| Distribution | If the remote server is also to receive traffic continuously, it is added with a lower Weight; an algorithm that uses the weight, such as Weighted Round Robin, is selected on the vService. |
Load Balancer or GTM?
| Your situation | Solution |
|---|---|
| The local servers are the main ones, the remote server is the backup | The remote server is added as a Backend Service, and Backup Service is marked |
| A small number of remote servers will receive traffic together with the local servers | The remote server is added with a low Weight |
| Both data centers will serve together, each with its own TR7 and servers, and users will go to the nearest center | Routing at the DNS level with GTM |
Common Misconceptions
- "A remote server behaves like a local server." Each request experiences the WAN latency; users who go to the remote server receive slower responses.
- "If a domain name is written, changes are reflected immediately." The domain name in the Backend Service address is resolved while the vService configuration is loaded; if the DNS record changes, the new address is used the next time the vService is reloaded.
- "With Use Client IP, the client IP is carried to the remote server." If the responses of the remote server do not return to TR7, the connections are not completed; in this case, X-Forwarded-For or Proxy Protocol is used.
How it is done in the documentation
