From 87023d99af892851523d5422bd162dc0e57d7c35 Mon Sep 17 00:00:00 2001 From: Rowena Date: Fri, 30 May 2025 15:21:38 +0200 Subject: [PATCH] fix(lb): clarify backend server rules --- macros/network/lb-create-backend-2-traffic-mgnt.mdx | 2 +- pages/load-balancer/concepts.mdx | 2 ++ pages/load-balancer/reference-content/configuring-backends.mdx | 2 ++ 3 files changed, 5 insertions(+), 1 deletion(-) diff --git a/macros/network/lb-create-backend-2-traffic-mgnt.mdx b/macros/network/lb-create-backend-2-traffic-mgnt.mdx index c216b15dcd..2b73963bfa 100644 --- a/macros/network/lb-create-backend-2-traffic-mgnt.mdx +++ b/macros/network/lb-create-backend-2-traffic-mgnt.mdx @@ -11,7 +11,7 @@ Traffic management configuration lets you define how your Load Balancer's backen * **Least connections**: Requests are forwarded to the backend server with the fewest current connections. * **First available**: Requests are forwarded to the first backend server with available connection slots. -2. Add the **Server IP addresses** of the servers the Load Balancer will forward requests/connections to. These will be your backend servers. +2. Add the **Server IP addresses** of the servers the Load Balancer will forward requests/connections to. These will be your backend servers. They must be Scaleway resources (Instances, Elastic Metal or Dedibox servers) unless you have a [Multi-Cloud](/load-balancer/faq/#what-is-the-difference-between-multi-cloud-and-non-multi-cloud-offers) Load Balancer, in which case this restriction does not apply. Scaleway backend servers can be in any AZ, and are not restricted to the same AZ as the Load Balancer. If you want your Load Balancer to communicate with its backend servers over an attached [Private Network](/vpc/concepts/#private-networks), ensure that you enter the servers' private IP addresses. This is necessary in the case of a [private Load Balancer](/load-balancer/reference-content/public-private-accessibility/#private-load-balancers), but may also be desired for public Load Balancers attached to Private Networks where backend servers are in the same VPC. As Load Balancers are compatible with [VPC routing](/vpc/reference-content/understanding-routing/), they will be able to direct requests to any backend server within the same VPC, via its private IP address. The Load Balancer and backend server do not have to be on the same Private Network in that VPC. diff --git a/pages/load-balancer/concepts.mdx b/pages/load-balancer/concepts.mdx index 66e513d53d..f3d44be28d 100644 --- a/pages/load-balancer/concepts.mdx +++ b/pages/load-balancer/concepts.mdx @@ -35,6 +35,8 @@ Each Load Balancer is configured with one or several backends. A backend represe The term "backend server" designates the final-destination backend servers which the Load Balancer forwards traffic on to. Each of the Load Balancer's [backends](#backends) must specify one or more backend servers (via their IP addresses) to forward to. +Backend servers must be Scaleway resources (Instances, Elastic Metal or Dedibox servers) unless you have a [Multi-Cloud](/load-balancer/faq/#what-is-the-difference-between-multi-cloud-and-non-multi-cloud-offers) Load Balancer, in which case this restriction does not apply. Scaleway backend servers can be in any AZ, and are not restricted to the same AZ as the Load Balancer. + ## Backend protection Backend protection is a set of configurable values that allow you to control how load is distributed to backend servers. You can use these settings to configure the **maximum number of simultaneous requests** to a given backend server before it is considered to be at maximum capacity. You can also configure a **queue timeout** value, which defines the maximum amount of time (in ms) to queue a request or connection for a particular backend server when [stickiness](#sticky-session) is enabled. Once this value is reached, the request/connection will be directed to a different backend server. diff --git a/pages/load-balancer/reference-content/configuring-backends.mdx b/pages/load-balancer/reference-content/configuring-backends.mdx index d94601e6e7..5541dd5a74 100644 --- a/pages/load-balancer/reference-content/configuring-backends.mdx +++ b/pages/load-balancer/reference-content/configuring-backends.mdx @@ -101,6 +101,8 @@ Load Balancers support three different modes of balancing load (requests) betwee You can add one or more IP addresses, either IPv4 or IPv6, of the backend servers your Load Balancer's backend will forward traffic to. +Backend servers must be Scaleway resources (Instances, Elastic Metal or Dedibox servers) unless you have a [Multi-Cloud](/load-balancer/faq/#what-is-the-difference-between-multi-cloud-and-non-multi-cloud-offers) Load Balancer, in which case this restriction does not apply. Scaleway backend servers can be in any AZ, and are not restricted to the same AZ as the Load Balancer. + ### Sticky sessions When activated, sticky sessions bind a user's session to a specific server in the pool of backend servers. This ensures that all subsequent sessions from the user are sent to the same backend server while there is at least one active session. Sticky sessions can be **cookie-based** or **IP-based** (aka table-based).