← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-tunnel / routing-to-tunnel

Общедоступные балансировщики нагрузки

A публичный балансировщик нагрузки позволяет распределять трафик между серверами, на которых работает ваш опубликованные приложения.

Когда вы добавляете маршрут опубликованного приложения к вашему Cloudflare Tunnel Cloudflare создаёт субдомен cfargotunnel.com с UUID созданного туннеля. Добавить приложение в пул балансировщика нагрузки можно с помощью <UUID>.cfargotunnel.com в качестве адрес конечной точки и указания имени хоста приложения (app.example.com) в заголовок Host конечной точки. Load Balancer не поддерживает прямое добавление app.example.com как конечную точку, если служба находится за Cloudflare Tunnel.

Создать публичный балансировщик нагрузки

Предварительные требования

Cloudflare Tunnel с маршрут опубликованного приложения

Создайте балансировщик нагрузки

Чтобы создать балансировщик нагрузки для приложений, опубликованных через Cloudflare Tunnel:

На панели управления Cloudflare перейдите к разделу Load Balancing страницу.
Перейдите в Load Balancing ↗
Выберите Создать балансировщик нагрузки, затем выберите Общедоступный балансировщик нагрузки.
В разделе Выберите веб-сайт, выберите домен маршрута опубликованного приложения.
На Имя хоста странице укажите имя хоста для балансировщика нагрузки (например, lb.example.com).
На Пулы странице выберите Создать пул и введите понятное название.
Добавьте endpoint туннеля со следующими значениями:
- Endpoint Name: Название сервера, на котором запущено приложение
- Endpoint Address: <UUID>.cfargotunnel.com (найдите Tunnel ID в [панели управления Cloudflare](https://dash.cloudflare.com/) в разделе **Networking** > **Tunnels**)
- Значение заголовка: Имя хоста маршрута вашего опубликованного приложения (например, app.example.com)
- Вес: 1 (если конечная точка только одна)
Примечание
Примечание
Один пул источников не может дважды ссылаться на один и тот же UUID туннеля.
Выберите Резервный пул. См. политики управления трафиком для параметров маршрутизации.
(Рекомендуется) На Мониторы странице привяжите монитор к конечной точке. Для приложения HTTP или HTTPS создайте монитор HTTPS:
- Type: HTTPS
- Путь: /
- Порт: 443
- Ожидаемый код(-ы): 200
- Header Name: Host
- Значение: app.example.com
Сохраните и разверните балансировщик нагрузки.

Чтобы протестировать, откройте приложение, используя имя хоста балансировщика нагрузки (lb.example.com).

См. документация Load Balancing с дополнительными сведениями о настройках и конфигурациях балансировщика нагрузки.

Дополнительные настройки Cloudflare

Приложение будет использовать настройки Cloudflare по умолчанию для имени хоста балансировщика нагрузки, включая Правила, Cache Rules и Правила WAF. Вы можете изменить настройки для своего имени хоста в Панель управления Cloudflare ↗.

Распространённые архитектуры

Ознакомьтесь с типичными конфигурациями балансировки нагрузки для опубликованных приложений за Cloudflare Tunnel.

Одно приложение на балансировщик нагрузки

Предположим, что в этом примере у нас есть веб-приложение, работающее на серверах в двух разных дата-центрах. Мы хотим подключить приложение к Cloudflare, чтобы пользователи могли обращаться к нему из любой точки мира. Кроме того, мы хотим, чтобы Cloudflare распределяла нагрузку между серверами так, чтобы при отказе основного сервера весь трафик принимал резервный сервер.

graph LR
		subgraph LB["Public load balancer <br> app.example.com "]
			subgraph P1[Pool 2]
				E1(["**Endpoint:** &lt;UUID_1&gt;.cfargotunnel.com<br> **Host header**: server2.example.com"])
			end
			subgraph P2[Pool 1]
				E2(["**Endpoint:** &lt;UUID_2&gt;.cfargotunnel.com<br> **Host header**: server1.example.com"])
			end
		end
		R@{ shape: text, label: "app.example.com" }
		R--> LB
    P1 -- Tunnel 1 --> cf1
    P2 -- Tunnel 2 --> cf2
		subgraph D2[Private network]
			subgraph r1[Region eu-west-1]
			cf1@{ shape: processes, label: "cloudflared <br> **Route:** server2.example.com" }
			S1(["Server 2<br> 10.0.0.1:80"])
			cf1-->S1
			end
			subgraph r2[Region us-east-1]
			cf2@{ shape: processes, label: "cloudflared <br> **Route:** server1.example.com" }
			S3(["Server 1 <br> 10.0.0.2:80"])
			cf2-->S3
			end
		end

		style r1 stroke-dasharray: 5 5
		style r2 stroke-dasharray: 5 5

Как показано на схеме, типичная конфигурация включает:

Отдельный Cloudflare Tunnel для каждого центра обработки данных.
Один пул балансировщика нагрузки на туннель. Имя хоста балансировщика нагрузки устанавливается равным имени хоста приложения, которое видит пользователь (app.example.com).
Одна конечная точка балансировщика нагрузки на пул. Заголовок Host этой конечной точки устанавливается равным cloudflared имя хоста опубликованного приложения (server1.example.com)
Как минимум два cloudflared реплики на туннель в соответствующих дата-центрах на случай, если cloudflared хост-машина выходит из строя.

Теперь пользователи могут подключаться к приложению, используя имя хоста балансировщика нагрузки (app.example.com). Обратите внимание, что эта конфигурация действительна только для Active-Passive failover, так как каждый пул поддерживает только одну конечную точку на туннель.

Несколько приложений на один балансировщик нагрузки

На следующей схеме показано, как с помощью одного балансировщика нагрузки направлять трафик к двум разным приложениям в приватной сети.

graph LR
		subgraph LB["Public load balancer <br> lb.example.com"]
			subgraph P1[Pool for App 1]
				E1(["**Endpoint:** &lt;UUID_1&gt;.cfargotunnel.com<br> **Host header**: app1.example.com"])
				E2(["**Endpoint:** &lt;UUID_2&gt;.cfargotunnel.com<br> **Host header**: app1.example.com"])
			end
			subgraph P2[Pool for App 2]
				E3(["**Endpoint:** &lt;UUID_1&gt;.cfargotunnel.com<br> **Host header**: app2.example.com"])
				E4(["**Endpoint:** &lt;UUID_2&gt;.cfargotunnel.com<br> **Host header**: app2.example.com"])
			end
		end
		R@{ shape: text, label: "app1.example.com <br> app2.example.com" }
		R--> LB
    E1 -- Tunnel 1 -->cf1
		E3 -- Tunnel 1 --> cf1
		E2 -- Tunnel 2 --> cf2
		E4 -- Tunnel 2 --> cf2

		subgraph N[Private network]
			cf2[cloudflared <br> **Route:** app1.example.com <br> **Route:** app2.example.com]
			S3(["App 1 <br> 10.0.0.1:80"])
			cf2-->S3
			cf2-->S1
			cf1[cloudflared <br> **Route:** app1.example.com <br> **Route:** app2.example.com]
			S1(["App 2 <br> 10.0.0.2:80"])
			cf1-->S1
			cf1-->S3
		end

Эта конфигурация балансировки нагрузки включает:

Two Cloudflare Tunnels with identical routes to both applications.
Один пул балансировщика нагрузки на приложение.
У каждого пула балансировщика нагрузки есть одна конечная точка на туннель.
A DNS-запись для каждого приложения, указывающего на хостнейм балансировщика нагрузки.

Теперь пользователи могут получать доступ ко всем приложениям через балансировщик нагрузки. Поскольку на пул приходится несколько конечных точек туннеля, эта конфигурация поддерживает Active-Active Failover. Active-Active использует все доступные конечные точки в пуле для одновременной обработки запросов, что обеспечивает более высокую производительность и масштабируемость за счет распределения нагрузки между ними.

DNS-записи

Когда вы настраиваете маршрут для опубликованного приложения через панель управления, Cloudflare автоматически создает CNAME DNS-запись, указывающая на имя хоста приложения (app1.example.com) к поддомену туннеля (<UUID>.cfargotunnel.com). Вы можете измените эти DNS-записи чтобы они указывали на имя хоста балансировщика нагрузки.

Ниже приведен пример того, как будут выглядеть ваши DNS-записи до и после настройки Несколько приложений на один балансировщик нагрузки:

До:

Type	Название	Content
CNAME	app1	`<UUID_1>.cfargotunnel.com`
CNAME	app2	`<UUID_1>.cfargotunnel.com`
CNAME	app1	`<UUID_2>.cfargotunnel.com`
CNAME	app2	`<UUID_2>.cfargotunnel.com`

После:

Type	Название	Content
LB	`lb.example.com`	н/д
CNAME	app1	`lb.example.com`
CNAME	app2	`lb.example.com`

Известные ограничения

Мониторы и источники TCP-туннелей

Мониторы TCP не поддерживаются для конечных точек туннеля. Вместо этого создайте конечную точку проверки работоспособности на cloudflared хост и используйте HTTPS-монитор. Например, вы можете использовать cloudflared и верните фиксированный ответ с HTTP-статусом:

Добавьте маршрут опубликованного приложения для проверки работоспособности:
- Имя хоста: health-check.example.com
- Тип службы: HTTP_STATUS
- Код состояния HTTP: 200
Создайте монитор с такими настройками:
- Type: HTTPS
- Путь: /
- Порт: 443
- Ожидаемый код(-ы): 200
- Header Name: Host
- Значение: health-check.example.com

Этот монитор проверяет, что cloudflared доступно. Это не означает, что вышестоящая служба принимает запросы.

Привязка сессий и реплики

Балансировщик нагрузки не различает реплики того же туннеля. Если вы запускаете один и тот же UUID туннеля на двух отдельных хостах, балансировщик нагрузки рассматривает оба хоста как единую конечную точку. Чтобы поддерживать привязка сессии между клиентом и конкретным хостом, вам потребуется подключить каждый хост к Cloudflare с использованием отдельного UUID туннеля.

Предпочтение локального соединения

Если вы замечаете дисбаланс трафика между конечными точками в разных локациях, вам может понадобиться скорректировать конфигурацию балансировщика нагрузки.

Cloudflare использует Anycast-маршрутизация ↗ чтобы направлять запросы конечных пользователей в ближайший дата-центр. cloudflared предпочитает обслуживать запросы через соединения в том же дата-центре, что может влиять на распределение трафика между конечными точками.

Если вы выполните cloudflared реплики с одним и тем же UUID туннеля, рассмотрите возможность перехода на отдельные туннели для более детального контроля над управление трафиком.