← Справочные архитектуры / reference-architecture / architectures

Эталонная архитектура балансировки нагрузки

Cloudflare Load Balancing представляет собой SaaS-решение, которое позволяет организациям размещать приложения для глобальной аудитории пользователей и при этом значительно снижает нагрузку, связанную с обслуживанием, отказоустойчивостью, устойчивостью и масштабируемостью. Использование Cloudflare Load Balancing позволяет организациям решить следующие задачи:

• Эффективная обработка больших объёмов входящего трафика, особенно во время неожиданных всплесков нагрузки.
• Обеспечение постоянной доступности приложений и сервисов для пользователей.
• Поддержание быстрого времени отклика и оптимальной производительности для всех пользователей, особенно в периоды высокой нагрузки.
• Адаптация к изменяющимся требованиям трафика и обеспечение того, чтобы инфраструктура выдерживала рост.
• Помогая приложениям и сервисам противостоять атакам типа Distributed Denial of Service (DDoS).

Cloudflare Load Balancing построен на базе connectivity cloud Cloudflare: единой интеллектуальной платформы программируемых облачных сервисов, обеспечивающей защищённую связь по принципу «любой с любым» между всеми сетями (корпоративными и интернетом), облачными средами, приложениями и пользователями. Это одна из крупнейших глобальных сетей с дата-центрами более чем в 330 городах и подключением свыше 13,000 сетевых партнёров (peers). Она также представлена в ключевых интернет-обменниках шире, чем многие другие крупные технологические компании.

В результате Cloudflare работает в пределах ~50 ms от ~95% населения мира, подключённого к интернету. А поскольку все сервисы Cloudflare рассчитаны на работу в каждой точке присутствия сети, все запросы маршрутизируются, проверяются и фильтруются как можно ближе к своему источнику, что обеспечивает высокую производительность и стабильный пользовательский опыт.

В этом документе описана эталонная архитектура для организаций, которые хотят развернуть решения по балансировке нагрузки как для глобального, так и для локального управления трафиком.

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

Чтобы лучше разобраться в Cloudflare и его решении для балансировки нагрузки, рекомендуем следующие материалы:

• Что такое Cloudflare? | Сайт ↗ (5 минут на чтение) или видео ↗ (2 минуты)

• Обзор решения: Cloudflare Private Network Load Balancing ↗ (5 минут на чтение)
• Обзор решения: Cloudflare GTM Load Balancing ↗ (5 минут на чтение)
• Блог: Более эффективная балансировка нагрузки с Private IPs и Cloudflare Tunnels: безопасный путь к результативному распределению трафика ↗ (13 минут)

Прочитав эту эталонную архитектуру, вы узнаете:

• Как Cloudflare Load Balancing решает задачи балансировки нагрузки в приватной сети и управления глобальным трафиком.
• Как глобальная сеть Cloudflare расширяет возможности Cloudflare Load Balancing.
• Возможности Cloudflare Load Balancers и их применение в различных сценариях использования.
• Структура Cloudflare Load Balancer и различные варианты его конфигурации.

В этом документе термин «endpoint» обозначает любой сервис или аппаратное устройство, которое принимает и обрабатывает входящий публичный или частный трафик. Поскольку балансировка нагрузки применяется не только к веб-серверам, термин endpoint выбран для обозначения всех возможных типов исходных серверов, хостнеймов, частных или публичных IP адресов, виртуальных IP адресов (VIP), серверов и других выделенных аппаратных устройств. Это может быть локальная инфраструктура, публичное или частное облако и даже сторонний балансировщик нагрузки.

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

Уровень 7 ↗ из Модель OSI ↗, также известный как прикладной уровень, содержит такие протоколы, как SSH, FTP, NTP, SMTP и HTTP(S). Когда в этом документе упоминается уровень 7 или балансировщики нагрузки уровня 7, имеются в виду сервисы на основе HTTP(S). Стек уровня 7 Cloudflare позволяет применять к сайту клиента такие сервисы, как защита от DDoS, Bot Management, WAF, CDN, балансировка нагрузки и другие, повышая производительность, доступность и безопасность.

Уровень 4 модели Модель OSI ↗ (также называемый транспортным уровнем) отвечает за сквозное взаимодействие между двумя устройствами. Сетевые сервисы, работающие на уровне 4, поддерживают гораздо более широкий набор служб и протоколов. Публичные балансировщики нагрузки Cloudflare уровня 4 реализованы в продукте Spectrum, который работает как обратный прокси уровня 4. Помимо балансировки нагрузки, Spectrum обеспечивает защиту от DDoS-атаки ↗ и позволяет скрывать IP адреса конечных точек.

SSL (Secure Sockets Layer) и его преемник TLS (Transport Layer Security) представляют собой криптографические протоколы, которые используются для защиты соединений в интернете. Разгрузка SSL и TLS, также известная как терминирование SSL/TLS или ускорение SSL/TLS, применяется в балансировщиках нагрузки и на веб-серверах для обработки шифрования и расшифровки SSL/TLS без влияния на производительность конечной точки. Разгрузка SSL/TLS повышает производительность сервера, упрощает управление сертификатами и увеличивает масштабируемость за счёт переноса ресурсоёмких задач шифрования и расшифровки на выделенные устройства, позволяя конечным точкам сосредоточиться на обслуживании контента и логики приложений.

Современные сайты, да и любые приложения, сталкиваются с тремя основными проблемами:

1. Производительность: Обеспечение своевременного отклика приложения на запросы и действия пользователей
2. Доступность: Поддержание доступности приложения, чтобы оно всегда могло отвечать на запросы пользователей
3. Масштабируемость: Увеличение, уменьшение или перемещение ресурсов приложения в зависимости от поведения пользователей или спроса.

На производительность приложения может влиять множество факторов, но чаще всего проблемы возникают из-за объёма нагрузки на конечную точку. У конечной точки, как правило, ограниченный запас вычислительных ресурсов. Если одновременно поступает слишком много запросов или запросы приводят к повышенному расходу CPU и памяти, конечная точка начинает отвечать медленнее или вовсе перестаёт отвечать.

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

Рисунок 1 показывает, как может распределяться нагрузка без балансировщика нагрузки:

Балансировщики нагрузки позволяют организациям размещать несколько конечных точек и распределять между ними трафик, не допуская перегрузки какой-либо одной из них. Балансировщик нагрузки принимает все входящие запросы и направляет их на подходящую конечную точку. Клиенту не требуется знать о доступности или нагрузке конечных точек: ему достаточно отправить запрос балансировщику, а дальше тот берёт всё на себя. На рисунке 2 показано, как балансировщик нагрузки равномерно распределяет трафик пользователей между набором конечных точек.

Ещё одна проблема, связанная с производительностью, касается расстояния между клиентом и конечной точкой. Из-за того, что запросу приходится преодолевать большее расстояние или делать больше сетевых переходов, время прохождения сигнала туда и обратно (RTT) у него, как правило, выше.

Значение RTT становится критически важным при масштабировании. Например, если клиент и конечная точка находятся в США, разумно ожидать RTT около 25ms. Если клиенту нужны ответы на 20 запросов, общее время их последовательной обработки (без учета времени вычислений) составит 500ms (20 x 25ms). А если тот же клиент подключается из региона APAC, RTT может достигать 150ms и более, что приводит к нежелательному общему времени загрузки в 3000ms (20 x 150ms). (Разумеется, улучшения потоковой передачи запросов в HTTP/2 и HTTP/3 могут изменить эти расчеты, однако для сайтов с динамическим или интерактивным контентом, где данные ответа используются для формирования дополнительных запросов, пример в целом остается верным.) Рисунок 3 показывает, как это происходит.

Так же, как балансировщик нагрузки может направлять трафик на менее загруженную конечную точку, он может направлять его и на географически более близкую конечную точку, за счёт чего клиент получает более быстрый отклик. А именно, балансировщик нагрузки определяет IP адрес отправителя запроса, вычисляет его местоположение и выбирает ближайшую или наиболее подходящую по региону конечную точку (это похоже на функциональность, которую предоставляют DNS решения вроде GeoDNS).

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

Балансировщики нагрузки решают эти проблемы, постоянно отслеживая работоспособность конечных точек. Если конечная точка медленно отвечает на проверку работоспособности или вообще не отвечает, она помечается как неработоспособная. Для мониторинга применяется несколько методов, включая базовые проверки, такие как ICMP (ping) и проверки TCP-соединения. Могут использоваться и более сложные проверки, например отправка HTTP-запроса GET с проверкой того, что от конечной точки получены определённые код ответа и тело ответа. Как только конечная точка переходит в деградировавшее состояние, балансировщик нагрузки начинает направлять на неё меньше запросов или не направлять их вовсе, отдавая предпочтение более работоспособным конечным точкам. Когда конечная точка снова становится работоспособной и балансировщик получает успешные ответы на проверки, она помечается как работоспособная, и трафик снова начинает направляться на неё.

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

Грамотное масштабирование приложений помогает организациям удовлетворять спрос клиентов и пользователей, не переплачивая за лишние ресурсы. При росте трафика может потребоваться временно развернуть больше конечных точек, чтобы сервис оставался производительным и доступным. Однако постоянно держать наготове столько конечных точек, чтобы покрыть максимально возможный трафик, может быть дорого, независимо от того, размещены они локально или у облачного провайдера вроде AWS, GCP или Azure. Балансировщики нагрузки позволяют динамически увеличивать или уменьшать ёмкость, отслеживая запросы, соединения и задержку до конечных точек.

Ещё один тип масштабирования, который стоит учитывать: географическое масштабирование. По мере роста популярности сервисов расположение конечных точек приобретает всё большее значение. Пользователи из региона, отличного от региона конечной точки, могут получать более медленный отклик и худшее качество обслуживания, чем пользователи из того же региона. Разворачивая новые конечные точки в разных регионах, организации вынуждены решать, как распределять между ними трафик. Эту задачу решают разные уровни балансировки нагрузки: глобальное управление трафиком (GTM) и Private Network Load Balancing. Оба этих механизма подробно описаны в следующем разделе. Кратко говоря, балансировщик GTM обрабатывает исходный запрос (как правило, через DNS), а затем выбирает и направляет трафик к Private Network Load Balancer, развёрнутому рядом с конечными точками в нужном географическом регионе.

Как уже говорилось, балансировка нагрузки для глобальных приложений и сервисов состоит из двух уровней. Первый уровень называется Global Traffic Management, или Manager (GTM), его также могут называть Global Server Load Balancing (GSLB). Второй уровень называется Private Network Load Balancing, его также могут называть Server Load Balancing (SLB). В этом разделе объясняется назначение этих видов балансировки нагрузки и то, как они работают вместе.

Global Traffic Manager отвечает за маршрутизацию запросов, как правило поступающих из интернета, в нужный регион или центр обработки данных. Многие балансировщики нагрузки GTM работают на уровне DNS, что позволяет им:

• Преобразовывать DNS-запрос в IP-адрес в зависимости от географического региона или физического местоположения.
• Предоставить IP-адрес ближайшей к клиенту конечной точки или сервиса, чтобы обеспечить подключение.

Рисунок 4 показывает, как балансировщик нагрузки GTM выбирает дата-центр на основе местоположения или региона клиента.

Global Traffic Manager также может проксировать трафик и выполнять различные проверки, включая чтение, изменение и удаление заголовков в HTTP-запросах, а также изменение URL-адресов в зависимости от региона или географического положения. Функциональность GTM лучше всего реализуется облачными балансировщиками нагрузки, например Cloudflare, поскольку цель заключается в управлении трафиком из любой точки мира. Аппаратные балансировщики нагрузки находятся в одном физическом месте, поэтому чем дальше источник трафика от балансировщика, тем медленнее становится работа для конечного пользователя. Облачный балансировщик нагрузки может работать в разных географических точках, что позволяет ему обеспечивать высокую производительность в сценариях DNS-only, а также на уровне 4 и уровне 7.

Балансировка нагрузки частной сети направляет трафик в пределах одного дата-центра или географического региона. Балансировщик нагрузки частной сети может отвечать за балансировку нагрузки, разгрузку SSL/TLS, переключение контента и другие функции доставки приложений. Балансировка нагрузки частной сети обеспечивает эффективное распределение клиентских запросов между несколькими конечными точками, что повышает производительность и гарантирует высокую доступность. Балансировщики нагрузки частной сети обычно размещаются внутри частных сетей и используются для балансировки нагрузки как публично, так и приватно доступных ресурсов. На рисунке 5 ниже балансировщик нагрузки GTM выбрал дата-центр в Европе для направления запроса, после чего балансировщик нагрузки частной сети этого дата-центра направит его к нужной конечной точке.

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

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

• Локальные балансировщики нагрузки
  • Обычно реализуется на аппаратном уровне, однако может быть виртуализированным или программным решением
  • Ориентировано на максимальную производительность
• Облачные балансировщики нагрузки
  • Программное обеспечение, развёрнутое в публичной облачной инфраструктуре
  • Обрабатывать запросы ближе к источнику запроса

У каждого подхода есть свои плюсы и минусы. Локальные (on-premises) балансировщики нагрузки обычно находятся внутри частных сетей, которые полностью контролируются организацией. Такие балансировщики размещаются рядом с конечными точками, которые они обслуживают, поэтому задержка и RTT минимальны. Недостаток локальных балансировщиков в том, что они привязаны к одной физической локации. Из-за этого трафик из других регионов может идти с большой задержкой и высоким RTT. Кроме того, для добавления ещё одного дата-центра требуется закупать и разворачивать всё новое оборудование. Локальным балансировщикам обычно также нужны облачные балансировщики для географической балансировки трафика, чтобы направлять запросы в географически ближайший или подходящий по региону дата-центр. Преимущество облачных балансировщиков в том, что они могут работать практически в любом географическом регионе без забот о стойках, электропитании, охлаждении или обслуживании и способны масштабироваться без необходимости в новых шасси, модулях или более широких сетевых каналах. При этом облачные балансировщики увеличивают задержку и RTT между балансировщиком и конечными точками, поскольку обычно не размещаются рядом с теми точками, на которые направляют трафик.

Cloudflare предлагает облачный GTM с 2016 года, а в 2023 году начала добавлять возможности Private Network Load Balancing. В этом разделе рассматривается архитектура Cloudflare Load Balancing целиком, а также подробно разбираются доступные конфигурации и варианты настройки. Но сначала важно понять, какие преимущества дает Cloudflare Load Balancers уже сам факт работы в глобальной сети Cloudflare.

Cloudflare Load Balancing построен на базе connectivity cloud Cloudflare: единой интеллектуальной платформы программируемых облачных сервисов, обеспечивающей связь по принципу «любой с любым» между всеми сетями (корпоративными и интернетом), облачными средами, приложениями и пользователями. Это одна из крупнейших глобальных сетей с дата-центрами более чем в 330 городах и подключением свыше 13,000 сетевых партнёров (peers). Она также представлена в ключевых интернет-обменниках шире, чем многие другие крупные технологические компании.

В результате Cloudflare работает в пределах ~50 ms от ~95% населения мира, подключённого к интернету. А поскольку все сервисы Cloudflare рассчитаны на работу в каждой точке присутствия сети, весь трафик подключается, проверяется и фильтруется как можно ближе к источнику, что обеспечивает наилучшую производительность и стабильный пользовательский опыт.

Решение Cloudflare для балансировки нагрузки выигрывает благодаря использованию технологии anycast. Anycast позволяет Cloudflare анонсировать IP-адреса своих сервисов из каждого дата-центра по всему миру, поэтому трафик всегда направляется в ближайший к источнику дата-центр Cloudflare. Это означает, что проверка трафика, аутентификация и применение политик происходят близко к конечному пользователю, что обеспечивает стабильно высокое качество работы.

Anycast обеспечивает сбалансированную работу сети Cloudflare. При резком росте трафика нагрузка распределяется между несколькими дата-центрами, что помогает поддерживать стабильное и надежное соединение для пользователей. Кроме того, благодаря большой пропускной способности сети Cloudflare и интеллектуальной маршрутизации на основе AI/ML производительность остается стабильно высокой.

Для сравнения, многие другие поставщики балансировки нагрузки на основе SaaS используют Unicast-маршрутизацию, при которой один IP-адрес связан с одной конечной точкой и (или) одним дата-центром. Во многих таких архитектурах один IP-адрес затем привязывается к конкретному приложению, а значит, запросы к этому приложению могут проходить совершенно разные маршруты в зависимости от того, какое расстояние должен преодолеть трафик. Например, производительность может быть отличной для сотрудников, работающих в офисе рядом с конечными точками приложения, но низкой для удалённых сотрудников или тех, кто работает за рубежом. Unicast также усложняет масштабирование трафика: единственная точка обслуживания должна наращивать ресурсы при росте нагрузки, тогда как anycast-сети могут распределять трафик между множеством дата-центров и географических точек.

Рисунок 6 показывает, как использование сети Cloudflare позволяет географически удалённым друг от друга пользователям подключаться к своим ресурсам максимально быстро.

На рисунке 6 выше показано, что в каждом из этих дата-центров также работают другие сервисы Cloudflare, поскольку Cloudflare запускает каждый сервис в каждом дата-центре, обеспечивая пользователям единообразный опыт повсюду. Например, балансировщик нагрузки уровня 7 от Cloudflare также может задействовать другие сервисы, такие как защита от DDoS, CDN/Cache, Bot Management или WAF. Все эти дополнительные сервисы помогают защитить ваш сервис от лишнего трафика, будь то вредоносные запросы (блокируемые DDoS Protection, Bot Management или WAF), либо запросы, которые можно обслужить из кеша вместо обращения к endpoint. Все эти сервисы можно комбинировать по мере необходимости, чтобы сделать сервис или продукт максимально защищённым, отказоустойчивым и производительным.

У Cloudflare также есть служба оптимизации сети ↗ которая постоянно работает во всех дата-центрах, обеспечивая Cloudflare лучший маршрут между дата-центрами Cloudflare, а также отслеживает все доступные маршруты к конечным точкам. Это позволяет Cloudflare гарантировать доступность конечных точек в любой момент и при необходимости перенаправлять трафик на другие дата-центры Cloudflare для достижения конечной точки. После того как балансировщик нагрузки принял решение о том, на какую конечную точку направить трафик, этот трафик передаётся в сервис оптимизации сети Cloudflare для определения наилучшего маршрута до пункта назначения. На выбор маршрута может влиять функция Argo Smart Routing, которая при включении использует замеры времени TCP-соединений, чтобы найти дата-центр Cloudflare с наименьшей задержкой RTT до конечной точки. На рисунке 8 показано, как Argo Smart Routing помогает сократить время подключения к конечным точкам.

На поток трафика также влияет использование Cloudflare Tunnels. Данный документ подробно описывает Cloudflare Tunnels в следующем разделе. Поскольку Cloudflare Tunnels соединяют конечные точки с конкретными дата-центрами Cloudflare, трафик, предназначенный для этих конечных точек, должен проходить через соответствующий дата-центр. На рисунке 9 показано, как соединения с частными конечными точками через Cloudflare Tunnel обязательно проходят через дата-центр, в котором туннель завершается.

Обычно GTM и балансировщики нагрузки частной сети представляют собой либо отдельное оборудование, либо раздельные компоненты: SaaS (GTM) и аппаратную балансировку нагрузки частной сети. В Cloudflare возможности GTM и балансировки нагрузки частной сети объединены в единое SaaS-решение, что значительно упрощает настройку и управление. Больше не нужно создавать балансировщик GTM и направлять трафик к более локальным балансировщикам нагрузки частной сети. Все конечные точки можно подключить к Cloudflare напрямую, а трафик будет направляться в нужный регион, дата-центр и конечную точку из единой конфигурации балансировщика нагрузки. Хотя концепции GTM и балансировки нагрузки частной сети сохраняются, их реализация в Cloudflare сделана так, чтобы конфигурация балансировщика оставалась максимально простой и понятной. На рисунке 10 показано, как глобальный трафик можно направить из любого географического региона к конкретной конечной точке при необходимости.

Cloudflare Load Balancer, который часто называют виртуальным IP-адресом (VIP), настраивается с точкой входа. Обычно такой точкой входа служит запись DNS. Сначала балансировщик нагрузки применяет заданный алгоритм маршрутизации трафика, чтобы выбрать пул эндпоинтов, то есть группу эндпоинтов, отобранных по функции, географической области или региону. В конфигурации балансировщика нагрузки может быть один или несколько пулов эндпоинтов, а в каждом пуле, в свою очередь, один или множество эндпоинтов. После выбора пула эндпоинтов балансировщик применяет алгоритм маршрутизации к списку эндпоинтов и выбирает конкретный эндпоинт, на который направит трафик. На рисунке 11 показаны основные шаги от запроса клиента до эндпоинта в Cloudflare Load Balancer.

Определение Cloudflare Load Balancer делится на три основных компонента:

1. Health monitors: эти компоненты отвечают за отслеживание состояния конечных точек и классифицируют их как исправные (healthy) или критические, неисправные (unhealthy).
2. Пулы конечных точек: здесь определяются конечные точки и применяются мониторы работоспособности и управление выбором конечных точек.
3. Балансировщики нагрузки: этот компонент применяет списки пулов конечных точек и политики распределения трафика.

В следующих разделах подробно описаны доступные параметры и особенности настройки Cloudflare Load Balancer, начиная с управления трафиком (steering), которое применяется как в пуле конечных точек, так и в конфигурации балансировщика нагрузки.

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

Первый называется «traffic steering» и отвечает за определение того, какой пул конечных точек будет обрабатывать входящие запросы, как правило на основе близости или географического региона отправителя запроса. Концепция traffic steering тесно связана с идеей глобального управления трафиком.

Второй уровень применения steering наступает после выбора региона, центра обработки данных или пула конечных точек. На этом этапе балансировщику нагрузки нужно выбрать одну конечную точку, которая будет обрабатывать запрос или соединение, это называется ‘endpoint steering’. На обоих уровнях steering выполняется с помощью методов, подобранных под конкретные потребности клиента, развертывающего балансировщик нагрузки. Доступно несколько разных алгоритмов, но не все из них применимы к обоим типам steering.

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

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

Управление выбором конечных точек определяет, какая конечная точка получит запрос или соединение. Оно может выбирать конечную точку случайным образом, использовать ранее выбранную точку (если включена привязка сеансов) или выбирать наименее загруженную и быстрее всего отвечающую конечную точку для запроса или соединения. Управление выбором конечных точек тесно связано с Private Network Load Balancing, поскольку именно оно определяет конечный пункт назначения запроса или соединения.

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

Вес влияет на случайность выбора пула конечных точек или конечной точки для отдельного запроса или соединения в балансировщике нагрузки. При расчете веса не учитываются исторические данные или сведения о текущих соединениях, поэтому в течение коротких промежутков времени распределение может отклоняться от заданного. Однако при большом объеме трафика на длительных интервалах распределение будет всё точнее соответствовать весам, заданным в конфигурации. Важно учитывать, что после установления первого соединения привязка сессий (session affinity) имеет приоритет над настройками веса, поскольку она предназначена для направления последующих запросов к тому же пулу конечных точек или конечной точке. На рисунке 12 показан пример веса для двух пулов конечных точек с одинаковой емкостью и вероятностью выбора.

Некоторые алгоритмы, например Least Outstanding Request Steering, учитывают количество открытых запросов и соединений. Вес используется для определения того, какие конечные узлы или пулы конечных узлов способны обрабатывать больше открытых запросов или соединений. По сути, вес задаёт ёмкость конечных узлов или пулов конечных узлов независимо от выбранного метода маршрутизации.

Вес определяется как любое число от 0.00 до 1.00. Обратите внимание, что суммарный вес пулов конечных точек или конечных точек внутри пула не обязательно должен равняться 1. Вместо этого все веса складываются, а затем отдельное значение веса делится на эту сумму, чтобы получить вероятность выбора данной конечной точки.

Формула перевода веса в проценты: (вес конечной точки) ÷ (сумма всех весов в пуле) = (% трафика на конечную точку)

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

Пример 1:

• Определены три пула конечных точек, у каждого вес равен 1
• У каждого пула конечных точек вероятность быть выбранным составляет 33%

Пример расчёта для веса 1: (1) ÷ (1 + 1 + 1) = (.3333) (или 33.33%)

В этом примере проще всего было присвоить значение веса 1 каждому из пулов конечных точек. Но стоит отметить, что можно было использовать любое число от 0.01 до 1.00, лишь бы оно было одинаковым для всех трёх пулов. Например, если задать всем трём пулам значение .1 или даже .7, вероятность выбора каждого пула для получения трафика была бы одинаковой.

Поскольку для вычисления вероятности используется сумма весов, организации могут задавать любые значения, чтобы сделать эти параметры более понятными. В приведённых ниже примерах, поскольку у каждого конечного узла одинаковая ёмкость, каждому из них присваивается вес .1, а сумма этих значений используется как вес пула конечных узлов.

Пример 2

• Определены три пула конечных точек
• В каждом пуле конечных точек разное количество конечных точек, но все конечные точки имеют одинаковую ёмкость (capacity)
• Чтобы равномерно распределять нагрузку между конечными точками, для каждого пула конечных точек нужна своя вероятность

Пример расчёта для веса .4 : (.4) ÷ (.4 + .5 + .6) = (.2667) (или 26.67%)

Пример расчёта для веса .5 : (.5) ÷ (.4 + .5 + .6) = (.3333) (или 33.33%)

Пример расчёта для веса .6 : (.6) ÷ (.4 + .5 + .6) = (.4000) (или 40.00%)

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

Пример 3

• Определены три пула конечных точек
• У пула конечных точек 1 конечные точки имеют вдвое большую емкость по сравнению с пулом конечных точек 2 и пулом конечных точек 3
• Цель состоит в том, чтобы направить в пул конечных точек 1 в два раза больше трафика на каждую конечную точку
• В пуле Endpoint pool 1 четыре конечные точки, но с удвоенной ёмкостью: вес каждой конечной точки составит 0.2, а суммарный вес пула будет равен 0.8

Пример расчёта для веса .8 : (.4) ÷ (.8 + .5 + .6) = (.4211) (или 42.11%)

Пример расчёта для веса .5 : (.5) ÷ (.8 + .5 + .6) = (.2632) (или 26.32%)

Пример расчёта для веса .6 : (.6) ÷ (.8 + .5 + .6) = (.3157) (или 31.57%)

В этом последнем примере, поскольку четыре конечные точки в пуле 1 обладают вдвое большей ёмкостью по сравнению с остальными, при расчёте пул 1 рассматривается так, как будто в нём фактически 8 конечных точек, а не 4. Отсюда значение веса .8 вместо .4, как в примере 2.

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

Веса особенно полезны, когда один пул конечных точек располагает большими ресурсами, чем другой, или когда конечные точки внутри пула имеют разную производительность. Вес помогает равномерно задействовать все ресурсы с учётом их возможностей.

Off - failover представляет собой самую простую политику управления трафиком. Она использует порядок пулов конечных точек как список приоритетов, определяющий, в какой пул направлять трафик. Если первый пул в списке исправен и готов принимать трафик, будет выбран именно он. Поскольку off - failover недоступен для управления конечными точками, для их выбора применяется другой метод. Off - failover обычно используется в сценариях активного и резервного отказоустойчивого перехода, когда трафик обрабатывает основной дата-центр или группа конечных точек, и только при сбое трафик переключается на резервный пул конечных точек.

Random доступен как для управления трафиком, так и для управления конечными точками. Random распределяет трафик между ресурсами на основе веса, заданного как в конфигурации балансировщика нагрузки, так и внутри пула конечных точек. Значения веса, заданные в балансировщике нагрузки для каждого пула конечных точек, могут отличаться от значения веса, заданного для отдельной конечной точки внутри этого пула. Например, в конфигурации балансировщика нагрузки 70% трафика может направляться в один из двух пулов конечных точек, а затем внутри этого пула трафик может равномерно распределяться между четырьмя конечными точками. В предыдущем разделе, взвешенная маршрутизация, подробно объясняет, как используется вес и как выполняются расчёты, определяющие выбор пула конечных точек или конечной точки.

Hash steering: алгоритм распределения трафика между конечными точками, который использует вес конечной точки и исходный IP-адрес запроса для выбора конечной точки. В результате каждый запрос с одного и того же IP-адреса всегда направляется на одну и ту же конечную точку. Важно учитывать, что изменение порядка конечных точек, а также добавление или удаление конечных точек из пула может привести к другим результатам при использовании алгоритма хеширования.

Geo steering: алгоритм распределения трафика, доступный клиентам с тарифным планом Enterprise, который используется для привязки пулов конечных точек к определенным странам или географическим регионам. Эта функция может повысить производительность за счет направления трафика на конечные точки, расположенные ближе к пользователям. Она также помогает соблюдать законодательные и нормативные требования, направляя запросы пользователей из определенных регионов на ресурсы в этом же регионе или на ресурсы, отвечающие конкретным нормативным требованиям.

Динамическая балансировка трафика, или dynamic steering, представляет собой алгоритм балансировки трафика, доступный клиентам на плане Enterprise, который строит профили времени приёма-передачи (RTT). Значения RTT собираются при каждом запросе проверки работоспособности на основе ответа конечной точки на запрос монитора. При поступлении запроса Cloudflare анализирует данные RTT и сортирует пулы по этому показателю. Если данных RTT для пула в конкретном регионе или дата-центре ещё нет, Cloudflare направляет трафик на пулы в порядке отказоустойчивости. При первом включении динамической балансировки для пула конечных точек изменения вступают в силу не сразу, Cloudflare требуется около 10 минут, чтобы построить профиль RTT для этого пула. Динамическая балансировка не учитывает географические границы и ориентируется исключительно на выбор пула конечных точек с наименьшим RTT.

Proximity steering представляет собой алгоритм управления трафиком, доступный клиентам с тарифом Enterprise. Он направляет трафик в ближайший физический дата-центр в зависимости от места происхождения запроса.

Cloudflare определяет физическое местоположение запрашивающей стороны следующими способами, в указанном порядке:

1. EDNS Client Subnet ↗ информации, если она указана в DNS-запросе
2. Информация о геолокации резолвера, используемого для обращения к Cloudflare
3. GPS-координаты дата-центра Cloudflare, обрабатывающего запрос

Для Proximity steering необходимо указать GPS-координаты для всех пулов конечных точек, чтобы Cloudflare мог определить ближайший пул конечных точек на основе IP-адреса запроса, DNS-резолвера или дата-центра Cloudflare.

Распределение по наименьшему числу необработанных запросов (LORS) доступно клиентам на тарифе Enterprise и может применяться как для распределения трафика, так и для распределения нагрузки между конечными точками.

LORS использует количество необработанных HTTP-запросов для влияния на распределение трафика и работает только с балансировщиками Cloudflare Load Balancer, проксируемыми через Cloudflare Layer 7. Если LORS назначен балансировщику другого типа, его поведение будет эквивалентно произвольному распределению трафика. LORS использует количество открытых запросов вместе с весом, чтобы сформировать новый преобразованный вес, который применяется при принятии решения о распределении трафика.

Формула преобразованного веса LORS:

• weight / (count + 1) = transformedWeight

Напоминание о расчете случайного веса:

• weight / (total weight) = вероятность быть выбранным

Вот пример LORS:

• Вес пула A равен 0.4
• Вес пула B равен 0.6
• У пула A 3 открытых запроса
• У пула B 0 открытых запросов
• Соответствующее уравнение
  • weight / (count + 1) = transformedWeight
• Преобразованный вес пула A: 0.4 / (3 + 1) = 0.1
• Преобразованный вес пула B: 0.6 / (0 + 1) = 0.6
• Соответствующее уравнение
  • weight / (total weight) = вероятность быть выбранным
• Вероятность того, что запрос будет направлен в пул A: 0.1 / (0.1+0.6) = .1429 (14.29%)
• Вероятность того, что запрос будет направлен в пул B: 0.6 / (0.1+0.6) = .8571 (85.71%)

В этом примере вероятность того, что следующее соединение будет направлено в Pool A, составляет 14.29%, а в Pool B, 85.71%. Хотя трафик, скорее всего, пойдёт в Pool B, направление в Pool A всё равно возможно. При небольшой нагрузке разброс результатов распределения будет больше и может не точно соответствовать заданным весам. Но по мере роста нагрузки фактические результаты распределения будут всё точнее соответствовать заданным весам.

При использовании балансировщиков нагрузки без проксирования на уровне L7 совместно с LORS информация о количестве открытых запросов недоступна. В результате знаменатель всегда равен 1. Поскольку деление любого числа на 1 не меняет числитель, а в данном случае числителем является вес, решения о распределении трафика будут приниматься исключительно на основе веса. Это приводит к случайному методу, описанному выше.

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

Все методы управления трафиком, отмеченные выше как доступные только на плане Enterprise, также можно получить в виде дополнения по подписке самообслуживания. Все методы управления конечными точками, отмеченные как доступные только на плане Enterprise, требуют наличия плана Enterprise в Cloudflare.

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

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

Функция Simulate Zone гарантирует, что проверки работоспособности идут по тому же маршруту, что и запросы HTTP/HTTPS уровня 7 для этой зоны, проходя через ту же программно определяемую маршрутизацию Cloudflare для исходящего трафика к источнику. Благодаря этому проверки работоспособности достигают конечной точки источника тем же путём через сеть Cloudflare и остальные процессы уровня 7, что и обычные запросы.

Функция Simulate Zone требуется для проверок работоспособности, если на уровне зоны включены определённые функции, например Authenticated Origin Pulls или Bring your own CA, где проверки завершались бы ошибкой при отсутствии корректного сертификата mTLS или центра сертификации для аутентификации на исходном сервере. Simulate Zone также гарантирует, что проверки работоспособности используют тот же путь, что указан в Argo Smart Routing и тот же самый Dedicated CDN Egress IPs когда организации используют Smart Shield Advanced чтобы ограничить edge IP-адреса, которые Cloudflare использует для обращения к их конечным точкам.

Probes для health monitor можно настроить в виде следующих типов:

• HTTP
• HTTPS
• TCP
• UDP ICMP
• ICMP Ping
• SMTP
• LDAP

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

• Пул конечных точек в исправном состоянии
  • Содержит только работоспособные конечные точки
• Пул конечных точек в состоянии деградации
  • Содержит хотя бы одну критическую конечную точку, но остаётся на уровне порога работоспособности или выше
• Пул конечных точек в критическом состоянии
  • Содержит работоспособные конечные точки, число которых ниже порога работоспособности
  • Не может обрабатывать трафик; исключён из всех решений о перенаправлении трафика.

После настройки health monitor в пуле конечных точек вторым шагом нужно определить, из каких регионов внутри глобальной сети Cloudflare должны исходить проверки health monitor. Доступные варианты перечислены ниже:

• Все регионы (по умолчанию)
• Все дата-центры (только Enterprise)
• Западная Северная Америка
• Восточная Северная Америка
• Западная Европа
• Восточная Европа
• Северная часть Южной Америки
• Южная часть Южной Америки
• Океания
• Ближний Восток
• Северная Африка
• Южная Африка
• Южная Азия
• Юго-Восточная Азия
• Северо-Восточная Азия

За исключением значений «All Regions» и «All Data Centers», проверки health monitor будут выполняться только из дата-центров выбранного региона или регионов. Для сервисов, актуальных лишь в конкретном регионе, обычно неважно, может ли до эндпоинтов достучаться дата-центр на другом конце света. Поэтому ограничение проверок конкретным регионом или набором регионов зачастую оправдано. Значения «All Regions» и «All Data Centers» предназначены для глобально доступных сервисов, для которых доступность всего набора эндпоинтов критична для работы приложения.

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

Конечные точки Cloudflare можно задать двумя способами: по IP-адресу или по имени хоста. IP-адрес представляет собой самый простой и базовый способ подключения, тогда как имя хоста дает несколько вариантов на выбор. Имя хоста можно задать в DNS Cloudflare, причем запись может быть проксируемой или работать только как DNS без проксирования. Есть и другой вариант: имя хоста относится к домену, для которого Cloudflare не выступает авторитативным DNS-сервером, и тогда Cloudflare будет обращаться к внешним DNS-серверам, чтобы преобразовать это имя в IP-адрес. Также можно использовать Cloudflare Tunnel, который предлагает еще два варианта. Все эти способы рассматриваются далее в этом разделе.

Как уже говорилось в разделе «HTTP(S) Load Balancing» выше, балансировка нагрузки выполняется самой последней перед отправкой запроса на конечную точку. Однако даже если конечная точка проксируется через периферийную сеть Cloudflare, после балансировщика нагрузки запрос направляется прямо на конечную точку, не проходя стек уровня 7 повторно. Это не означает, что конечная точка остаётся без защиты или кеширования. Пока сам балансировщик нагрузки проксируется, все эти механизмы защиты применяются к нему, а не к конечным точкам. Прямое обращение к конечной точке всё ещё может проксироваться и обрабатываться стеком уровня 7 Cloudflare, но при обращении к конечной точке вся обработка выполняется перед балансировщиком нагрузки, а не перед самой конечной точкой. На рисунке 19 показано, чем отличается расположение стека уровня 7 Cloudflare относительно конечной точки (точек).

С точки зрения балансировщика нагрузки тип конечной точки, определенной в составе пула, почти не имеет значения. После применения политик управления трафиком и выбора конечных точек, а также правил балансировки нагрузки служба Cloudflare Load Balancing указывает стеку L7, куда направить входящий запрос или соединение. Этот запрос отправляется непосредственно на конечную точку. В зависимости от типа соединения с конечной точкой путь может отличаться. Такие функции, как Argo Smart Routing или конечные точки, подключенные через туннель и терминируемые в разных дата-центрах Cloudflare, направляют трафик иначе, чем при отправке запроса за пределы периметра Cloudflare через интернет напрямую на конечную точку. Однако независимо от пути балансировка нагрузки остается последним процессом в стеке, а значит, трафик не получает никакой дополнительной обработки. Таким образом, хотя тип соединения с конечной точкой может изменить путь от Cloudflare до конечной точки, сама обработка после выбора конечной точки не меняется.

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

Cloudflare Tunnel (cloudflared) можно установить непосредственно на конечном узле или на любом сервере с IP-связностью с этим узлом. Поскольку соединение с Cloudflare инициируется именно с того места, где установлен Cloudflare Tunnel, требуется только исходящий доступ к Cloudflare. Один туннель Cloudflare Tunnel может передавать трафик к одному или нескольким конечным узлам двумя способами: в одном случае узел становится общедоступным, в другом остаётся доступным исключительно в частном порядке.

Cloudflare Tunnel можно установить непосредственно на конечном узле или на любом сервере со связностью на уровне 3 (IP) с узлом или узлами, которые нужно подключить к Cloudflare. Решение вынести cloudflared в отдельный компонент может приниматься по разным причинам, в том числе для изоляции конечных узлов и обеспечения их производительности, для разделения ответственности между командами, отвечающими за сетевой уровень и конечные узлы, или ради архитектурной простоты, когда серверы имеют чётко разделённые роли и обязанности.

Один экземпляр cloudflared создаёт 4 разных туннеля, по два в двух разных дата-центрах Cloudflare. Такая модель обеспечивает высокую доступность и снижает риск отказа отдельных соединений: если одно соединение, сервер или дата-центр выйдут из строя, эндпоинты останутся доступны. Cloudflare Tunnel также позволяет организациям развёртывать дополнительные экземпляры cloudflared для сценариев обеспечения доступности и отказоустойчивости. Такие отдельные экземпляры называются репликами. Каждая реплика устанавливает четыре новых соединения, которые служат дополнительными точками входа к эндпоинту (эндпоинтам). Все реплики указывают на один и тот же туннель, поэтому сеть остаётся доступной, даже если хост, на котором работает cloudflared, выйдет из строя. По своей природе реплики не выполняют никакой маршрутизации трафика (ни random, ни hash, ни round robin).

Метод public endpoint позволяет организациям задать туннель, указывающий на определённый сервис или порт на конечной точке. Туннель может завершаться на самой конечной точке или на любом сервере с IP связностью с ней. При использовании этого метода публичного имени хоста каждый сервис, доступ к которому будет осуществляться через туннель, должен быть определён в конфигурации туннеля. После настройки для IP адреса и порта или сервиса, трафик которого передаёт туннель, создаётся уникальный идентификатор туннеля, например d74b3a46-f3a3-4596-9049-da7e72c876f5. Затем на основе этого идентификатора туннеля создаётся уникальное публичное имя хоста в домене cfargotunnel.com, принадлежащем Cloudflare, в результате чего создаётся запись DNS A, указывающая непосредственно на этот сервис, то есть d74b3a46-f3a3-4596-9049-da7e72c876f5.cfargotunnel.com. Хотя это имя хоста является публичным, доступ к нему и его использование возможны только для трафика, отправленного через учётную запись, которой принадлежит конфигурация Cloudflare Tunnel. Никакие другие учётные записи не могут получить доступ или отправлять трафик напрямую на этот адрес DNS. Запись DNS CNAME, созданная за пределами учётной записи, которой принадлежит имя хоста cfargotunnel.com, не сможет передавать трафик через этот конкретный Cloudflare Tunnel.

При настройке через Dashboard Cloudflare автоматически создаёт в DNS-зоне запись CNAME, указывающую на имя хоста cfargotunnel.com. Например, можно создать запись CNAME myTunnelService.example.com, указывающую на запись A d74b3a46-f3a3-4596-9049-da7e72c876f5.cfargotunnel.com. Главное преимущество в удобстве использования и администрирования, поскольку запись CNAME гораздо понятнее отражает своё назначение и принадлежит DNS-зоне клиента.

Ещё один вариант: создать эти туннели и службы на хосте, где выполняется cloudflared. Это называется туннель с локальным управлением. При работе с туннелями, управляемыми локально, запись CNAME не создается автоматически, поэтому организации нужно настроить ее вручную после определения туннеля и сервиса.

С точки зрения балансировщика нагрузки очень важно понимать, как эти туннели можно использовать в качестве конечной точки. Конечную точку можно определить только с помощью хоста cfargotunnel.com. Использование публичной записи CNAME, указывающей на адрес cfargotunnel.com, работать не будет и не поддерживается. Это особенно важно для сервисов конечных точек, которые не работают на портах 80 или 443: по умолчанию балансировщики нагрузки Cloudflare обращаются к сервисам на конечных точках именно через эти два порта. Если у организации сервисы работают на других портах, ей потребуется настроить Cloudflare Tunnel с правило catch-all для доступа к этому порту. Такая конфигурация позволяет Cloudflare Load Balancer обращаться к сервису через порт 443, при этом Cloudflare Tunnel проксирует соединение на нужный порт конечной точки.

Второй метод предназначен для частных подсетей. Он позволяет организациям задать частные IP адреса и маску подсети, которые используются для создания частной виртуальной сети внутри глобальной сети Cloudflare. Метод частной подсети не позволяет указывать порт, поэтому после определения подсети и маски вся подсеть становится доступной через этот туннель, но только для пользователей организации, которым доступ разрешён заданными политиками Zero Trust.

Затем эта подсеть добавляется в виртуальную сеть внутри Cloudflare, где клиент может контролировать, как и какие пользователи получают к ней доступ. Подсеть можно задать с любым нужным разбиением или маршрутизацией, в том числе с 32-битной маской (единичный IP-адрес, например 10.0.0.1/32). При этом разрешённая подсеть не обязана существовать на хосте, где запущен процесс cloudflared. Требуется лишь связность на уровне L3 или IP-связность между хостом с cloudflared и подсетью, которая должна быть доступна через Cloudflare Tunnel.

В пуле эндпоинтов доступно несколько параметров настройки. В этом разделе описано, какие это параметры и как они меняют поведение Cloudflare Load Balancer.

Первый шаг настройки, помимо указания имени и описания пула конечных точек, это выбор метода распределения между конечными точками (endpoint steering). Он отвечает за итоговый выбор пула конечных точек или конкретной конечной точки, которая получит запрос или попытку подключения (см. Методы распределения трафика раздел, где подробно описан каждый метод).

Отдельные конечные точки задаются внутри пулов конечных точек, а пул позволяет задать одну или несколько конечных точек.

• имя конечной точки используется в первую очередь для справки, отчетности и аналитики и не влияет на работу балансировщика нагрузки или пула конечных точек.
• адрес конечной точки, однако определяет ресурс, который балансировщик нагрузки может использовать для обработки запроса или соединения.
  • Конечные точки в пуле конечных точек должны быть доступны через порт 80 или 443. Если конечная точка не прослушивает порт 80 или 443, перед ней необходимо разместить прокси-сервис или устройство перенаправления сетевых портов, чтобы сопоставить порт 80 или 443 с портом, который служба фактически прослушивает.
  • Ещё один способ сопоставить порты конечных точек с портами 80 или 443: подключиться к службе конечной точки с помощью Cloudflare Tunnel, а затем используйте имя хоста, созданное в ходе этого процесса, как адрес конечной точки. Это автоматически сопоставит нужный порт конечной точки с портом 443.

Адрес конечной точки можно задать одним из следующих способов:

• Общедоступный маршрутизируемый IP-адрес
• Публично доступное имя хоста, проксируемое через Cloudflare
• Общедоступное имя узла, не принадлежащее Cloudflare
• Частный, немаршрутизируемый в публичной сети IP-адрес с выбором виртуальной сети

Использование публичных IP-адресов и хостов любого типа не требует дополнительной настройки. В таких сценариях виртуальную сеть следует оставить со значением по умолчанию “нет”. «нет” означает, что эти ресурсы будут доступны в публичном интернете и будут проходить через глобальную периферийную сеть Cloudflare.

Использование виртуальная сеть вариант зарезервирован для приватных IP ресурсов. Этот параметр соответствует подсетям IP, которые расположены за Конфигурации Cloudflare Tunnel. Нужно выбрать виртуальную сеть, у которой есть маршрут к IP-адресу конечной точки. Чтобы перейти к этой настройке в Cloudflare Dashboard, выберите Networks - Routes со страницы Zero Trust.

Вес конечной точки используется только для методов маршрутизации random, hash и least outstanding request; его всегда необходимо задавать как часть определения конечной точки. (См. Взвешенное распределение раздел, где подробнее рассказано о том, как веса используются при выборе конечной точки.)

Пулы конечных точек позволяют изменить заголовок host перед отправкой запроса на конечную точку. Эта настройка применяется только к балансировщику нагрузки уровня 7 HTTP(S) и игнорируется при использовании балансировщиков уровня 4, включая private IP и Spectrum.

В балансировщике нагрузки 7 уровня, где запросы идут по HTTP(S), заголовок Host сообщает эндпоинту, какой именно сайт запрашивается, поскольку один эндпоинт может обслуживать несколько разных веб-доменов. Если эндпоинт настроен на обслуживание конкретного веб-домена, он может не ответить или вернуть ошибку на запрос ресурса, если считает, что не обслуживает ресурс, указанный в заголовке Host (то есть если заголовки Host не совпадают).

Например:

• Допустим, пользователь пытается обратиться к www.example.com. Load balancer будет настроен с hostname www.example.com чтобы получать все запросы.
• Поскольку конечные узлы не могут иметь одинаковое публичное имя хоста в DNS, в качестве его имени хоста используется endpoint1.example.com.
• Когда пользователь отправляет запрос к www.example.com, заголовок Host будет установлен в значение www.example.com. Конечную точку также нужно будет настроить так, чтобы она отвечала на заголовки Host вида www.example.com.
• В некоторых случаях (например, с определёнными облачными или SaaS-приложениями) конечные точки нельзя настроить подобным образом, поэтому они могут получить запрос с неизвестным заголовком Host и не суметь корректно на него ответить.
• В этом примере в конфигурации конечной точки заголовок Host для неё задаётся равным адресу конечной точки endpoint1.example.com заменит заголовок Host у www.example.com с endpoint1.example.com, и позволит конечной точке корректно отвечать на этот запрос.

Рисунок 21 показывает потенциальную проблему несовпадения заголовков Host:

Кроме того, для пула конечных точек можно указать GPS-координаты пула (которые используются при управлении трафиком по близости). Если управление по близости не используется, указывать эти координаты не требуется (см. Proximity Steering).

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

Параметр load shedding следует включать только тогда, когда администратор намеренно защищает пул конечных точек от перехода в неработоспособное состояние. Он активируется, например, если конечная точка всё ещё отвечает на запросы, но при этом испытывает повышенную нагрузку на CPU или память, увеличенное время отклика или периодически не отвечает вовсе.

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

В зависимости от состояния пула конечных точек иногда достаточно просто отбросить или перенаправить новые запросы и подключения от этого пула. Эта политика применяется к трафику, на который не действуют правила привязки сессий, поскольку речь идёт о новых подключениях, для которых пул или конечная точка ещё не выбраны (и поэтому это не повлияет на опыт конечного пользователя).

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

Health monitors привязываются к конечным точкам в пуле конечных точек, а также к порогу работоспособности и выбору региона проверки работоспособности. Подробности об этих параметрах можно найти в монитор состояния раздел.

Балансировка нагрузки в Cloudflare объединяет GTM и Private Network Load Balancing в единой конфигурации балансировщика нагрузки. Хотя некоторые функции или термины могут больше относиться к GTM или к Private Network Load Balancing, для клиентов Cloudflare оба варианта объединены в один удобный в управлении экземпляр.

В зависимости от конкретного сценария использования организации могут применять разные типы Cloudflare Load Balancers. В следующем разделе рассматриваются основные различия между моделями развёртывания и описывается, когда следует использовать каждый тип балансировщика нагрузки.

Рисунок 22 показывает все возможные комбинации балансировщиков нагрузки и конечных точек, поддерживаемые Cloudflare:

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

• Балансировка нагрузки Layer 7 HTTP(S)
• Балансировка нагрузки типа DNS-only
• Балансировка нагрузки Spectrum

За исключением варианта DNS-only балансировки нагрузки, который подробно описан ниже, во всех остальных моделях развёртывания трафик проходит через балансировщик нагрузки. Это означает, что пользователь или клиент, создающий запрос или соединение, никогда не знает, какие конечные точки используются для обработки этого запроса или соединения. Информацию о конечной точке при желании можно раскрыть с помощью заголовков, однако это не поведение по умолчанию ни для одной из таких моделей развёртывания с фиксированным трафиком.

Далее подробно рассматриваются четыре основные модели развертывания и их различия.

Во-первых, наиболее распространена модель Проксирующий балансировщик нагрузки уровня 7 на основе HTTP(S). Эти балансировщики нагрузки работают на периферийной сети Cloudflare и доступны публично. Среди прочих возможностей эта модель поддерживает WebSockets, представляющие собой открытые соединения между клиентом и конечной точкой, по которым данные передаются в обе стороны.

Поскольку этот же стек защиты уровня 7 также предоставляет WAF, защиту от DDoS, Bot Management, Zero Trust и другие сервисы, доступ к этим публичным балансировщикам нагрузки при необходимости можно ограничить только аутентифицированными и авторизованными пользователями. (См. Защита балансировщиков нагрузки подробнее.)

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

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

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

Как только запрос попадает в процесс балансировщика нагрузки, он всегда отправляется напрямую к выбранной конечной точке. Это значит, что даже если конечная точка проксируется через Cloudflare, запрос будет отправлен ей напрямую и больше не будет обрабатываться.

Для индивидуальной обработки после того, как балансировщик нагрузки выберет конечную точку, применяются Custom Rules балансировщика нагрузки. (Подробнее об этом см. в Балансировщики нагрузки раздел ниже).

Важные замечания о балансировщиках нагрузки HTTP(S) уровня 7:

• Балансировщики Layer 7 HTTP(S) поддерживают как публичные, так и приватные конечные точки
• Балансировщики Layer 7 HTTP(S) поддерживают только HTTP(S)- и WebSocket-трафик
• Политики Zero trust можно применять к балансировщикам нагрузки уровня 7 HTTP(S)

DNS-only load balancer Cloudflare представляет собой непроксируемый (unproxied) балансировщик нагрузки. Это означает, что через edge Cloudflare проходит только начальный DNS-запрос к ресурсу, а не сам трафик. Поэтому вместо того, чтобы DNS-запрос разрешался в IP-адрес Cloudflare и затем проходил через стек уровня 7, как было показано ранее на рисунке 7, Cloudflare получает DNS-запрос для DNS-only load balancer, применяет все соответствующие политики балансировки нагрузки, а затем возвращает клиенту IP-адрес для прямого обращения.

Поскольку весь трафик между клиентом и конечной точкой проходит напрямую между ними, минуя стек уровня 7 Cloudflare, балансировщик нагрузки, работающий только на уровне DNS, может поддерживать любой тип IP трафика.

Хотя Cloudflare не проксирует такие типы соединений балансировщика нагрузки, служба мониторов работоспособности продолжает отслеживать состояние всех конечных точек в пуле. В зависимости от работоспособности или доступности конечной точки балансировщик нагрузки Cloudflare DNS-only добавляет или удаляет соответствующую конечную точку из DNS-ответа, чтобы направлять трафик только на исправные конечные точки.

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

Решение о том, сколько IP-адресов включить в ответ DNS, один или несколько, зависит от веса, присвоенного конечным точкам в выбранном пуле конечных точек:

• Если веса всех конечных точек равны, в ответе DNS будут возвращены IP-адреса всех конечных точек.
• Если хотя бы у одной конечной точки в пуле задан уникальный вес, в ответе DNS будет возвращен только один IP-адрес, независимо от выбранного для пула метода управления трафиком.

Это даёт организациям гибкость: приложение может само видеть все конечные точки и выполнять локальное переключение при сбое, либо Cloudflare может предоставить приложению единый IP-адрес.

Рисунок 27 показывает, как заданный вес в пуле конечных точек влияет на ответ балансировщика нагрузки, использующего только DNS.

Обратите внимание, что балансировщики нагрузки в режиме DNS-only имеют ряд ограничений по сравнению с проксируемыми балансировщиками нагрузки:

• Балансировщик нагрузки больше не скрывает IP адрес конечной точки от клиента, так как ответ отправляется клиенту напрямую.
• У них нет встроенных служб уровня 7, упомянутых в предыдущей модели, то есть балансировщики нагрузки только с DNS не включают кеширование, WAF, защиту от DDoS или поддержку Zero Trust.
• Привязка сессии ограничена ip_cookie, который детерминированно выбирает конечную точку и затем привязывает ее к IP-адресу клиента для всех последующих запросов.
• Наконец, поскольку при использовании режима DNS only соединения не проксируются через балансировщик нагрузки, некоторые методы управления трафиком (steering) также не будут работать. Например, LORS не будет работать, посколь ку Cloudflare не будет знать о соединениях с конечными точками. В этом случае методы управления трафиком вернутся к случайному взвешенному распределению.

Дополнительные сведения о других методах управления трафиком см. в Распределение трафика раздел.

При использовании балансировщиков нагрузки только с DNS также следует учитывать кеширование DNS на стороне клиента и распознавателя. Время жизни кеша определяется DNS-сервером, отвечающим на запрос. Этот Время жизни (TTL) ↗ указывает DNS-клиенту, сколько времени ответ остается действительным, прежде чем нужно будет отправить новый DNS-запрос, чтобы проверить, не изменился ли адрес назначения. Значение TTL указывается в секундах, поэтому, например, TTL 3600 соответствует одному часу. При этом стандартные значения DNS TTL обычно составляют 12 или 24 часа, то есть 43200 и 86400 секунд соответственно.

Для балансировщика нагрузки DNS-only TTL установлен на 30 (секунд). Это гарантирует, что при изменении состояния конечных точек, а также при их добавлении или удалении запросы к балансировщику DNS-only выполняются чаще, чтобы список доступных конечных точек оставался максимально точным.

Важные замечания о балансировщиках нагрузки только для DNS:

• Балансировщики нагрузки типа DNS-only поддерживают только публичные конечные точки
• Балансировщики нагрузки типа DNS-only не проксируют трафик и поэтому не участвуют в соединениях с конечной точкой
• Балансировщики нагрузки типа DNS-only отвечают на DNS-запрос только IP-адресом или набором IP-адресов

Cloudflare также предлагает ещё один способ входящего подключения через Spectrum продукт.

Там, где стек уровня 7 поддерживает только HTTP(S) и WebSocket, Spectrum обеспечивает поддержку любого протокола на основе TCP или UDP. Cloudflare Load Balancer, использующий Spectrum как точку входа трафика, работает на уровне 4, где существуют протоколы TCP и UDP. Любая служба, использующая для передачи TCP или UDP, может задействовать Spectrum вместе с Cloudflare Load Balancer, включая SSH, FTP, NTP, SMTP и другие.

Учитывая широту охватываемых сервисов и протоколов, здесь применяется более общий подход, чем в стеке уровня 7 HTTP(S). Например, Cloudflare Spectrum поддерживает такие функции, как TLS/SSL offloading, защиту от DDoS, IP Access lists, Argo Smart Routing и сохранение сессий (session persistence) в наших балансировщиках нагрузки уровня 4.

Балансировщики нагрузки Cloudflare Spectrum уровня 4 доступны из интернета. Доступ к этим ресурсам балансировки нагрузки можно контролировать с помощью конфигурации Spectrum под названием IP Access Rules, которые можно задать как часть конфигурации WAF, но они ограничены правилами с действием «allow» или «block» для конкретных IP-адресов, подсетей, стран или Протокол граничных шлюзов (BGP) ↗ Номера автономных систем (ASN).

Помимо того что балансировщики нагрузки Spectrum всегда публичны, они всегда проксируются. Настройка прокси, показанная ранее (рисунки 24 и 25), будет игнорироваться, если Spectrum настроен как входной путь для балансировщика нагрузки. Весь трафик, предназначенный для балансировщиков нагрузки на базе Spectrum, всегда проходит через периметр сети Cloudflare.

Важные замечания о балансировщиках нагрузки Spectrum:

• Балансировщики нагрузки Spectrum поддерживают как публичные, так и приватные конечные точки
• Балансировщики нагрузки Spectrum изначально создаются как балансировщики уровня 7 (HTTP(S)). После этого создается приложение Spectrum с типом конечной точки Load Balancer, для которого выбирается уже созданный балансировщик нагрузки.
• Балансировщики нагрузки Spectrum всегда работают в режиме проксирования, независимо от значения переключателя Proxied в конфигурации балансировщика нагрузки
• Изменить входящий порт при подключении из интернета через Spectrum к конечной точке невозможно, то есть если трафик поступает в Spectrum на порт 22, он будет направлен на порт 22 конечной точки
• Балансировщики нагрузки Spectrum поддерживают привязку сессий только с использованием метода распределения по хешу конечной точки (hash)
• Балансировщики нагрузки Spectrum не поддерживают Custom Rules

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

Параметр proxy определяет, будет ли Cloudflare проксировать трафик для балансировщика нагрузки или просто предоставит ответ DNS с конечными точками для прямого подключения клиента. Подробнее это рассматривается в Модели развёртывания раздел.

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

Cloudflare предлагает три способа включить привязку сеансов (session affinity):

1. Только по cookie-файлу Cloudflare (cookie): При первом запросе к проксируемому балансировщику нагрузки создается cookie-файл, в котором закодирована информация о том, на какую конечную точку будет перенаправлен запрос. Последующие запросы (от того же клиента к тому же балансировщику нагрузки) будут отправляться на конечную точку, закодированную в cookie-файле: а) в течение срока действия cookie-файла и б) пока конечная точка остается исправной. Если срок действия cookie-файла истек или конечная точка неисправна, будет рассчитана и использована новая конечная точка.
2. По cookie-файлу Cloudflare с резервным вариантом по IP-адресу клиента (ip_cookie): Это работает аналогично описанному выше методу cookie, за исключением того, что cookie формируется на основе IP адреса клиента. В этом случае запросы с одного и того же IP адреса всегда направляются на одну и ту же конечную точку: a) в течение срока действия cookie и b) пока конечная точка остаётся работоспособной. Если срок действия cookie истёк или конечная точка неработоспособна, вычисляется и используется новая конечная точка.
3. По HTTP-заголовку (header): При первом запросе к проксируемому балансировщику нагрузки создается ключ сеанса на основе настроенных HTTP-заголовков. Последующие запросы к балансировщику нагрузки с теми же заголовками будут отправляться на ту же конечную точку: а) в течение срока действия сеанса или б) пока конечная точка остается исправной. Если сеанс простаивал в течение времени жизни привязки сеанса (TTL, в секундах) или конечная точка неисправна, будет рассчитана и использована новая конечная точка.

Эти три варианта привязки сеанса применяются только к балансировщикам нагрузки уровня 7 (HTTP(S)). Для привязки сеанса требуется TTL, который определяет, как долго балансировщик будет направлять последующие запросы на конкретную конечную точку. Значение TTL по умолчанию составляет 82 800 секунд (23 часа), но его можно задать в диапазоне от 1800 секунд (30 минут) до 604 800 секунд (семь дней).

При привязке сеанса на основе cookie таймер истечения никогда не сбрасывается: отсчёт идёт с начала сеанса независимо от того, активен он или простаивает. При привязке сеанса на основе HTTP-заголовка таймер истечения сбрасывается при каждой активности в рамках сеанса.

Draining конечных точек представляет собой подфункцию session affinity. Она позволяет сессиям на конечной точке плавно завершаться, не позволяя при этом создавать на ней новые сессии. Draining полезен при обслуживании, поскольку не требует от администраторов резко и произвольно обрывать пользовательские сессии, чтобы снять с конечной точки всю активную нагрузку.

TTL вывода конечной точки (endpoint drain TTL) представляет собой время, в течение которого конечные точки могут сохранять активные сессии до принудительного завершения. После того как TTL вывода задан, сам вывод конечной точки запускается отключением одной или нескольких конечных точек в пуле. Как показано на изображении ниже, администраторы могут отслеживать оставшееся время операции вывода в интерфейсе балансировщика нагрузки.

Draining конечных точек применим только вместе с session affinity, потому что без неё последующие запросы или соединения не гарантированно направляются на ту же конечную точку. Поэтому отключение конечной точки в этом случае не влияет на работу пользователей.

Отказоустойчивое переключение без простоя автоматически перенаправляет трафик на эндпоинты в пуле эндпоинтов при временных сетевых сбоях.

Функция Zero-Downtime Failover запускает только одну повторную попытку, если в пуле есть другая исправная конечная точка и код ошибки 521, 522, 523, 525 или 526 происходит. Никакие другие коды ошибок не запускают операцию отказоустойчивого переключения без простоя.

У отказоустойчивого переключения без простоя есть три режима работы:

1. Нет (Off): Аварийное переключение не произойдет, и пользователи могут получать сообщения об ошибках или сталкиваться с ухудшением качества работы.
2. Временно: Трафик будет направляться на другие конечные точки, пока исходная конечная точка снова не станет доступна.
3. Sticky: Cookie сессионной привязки обновляется, и при необходимости последующие запросы в дальнейшем направляются на новую конечную точку. Это не поддерживается, если сессионная привязка использует режим HTTP заголовков.

Адаптивная маршрутизация: отказоустойчивое переключение между пулами расширяет функциональность отказоустойчивого переключения без простоя (zero-downtime failover), позволяя переключаться на конечные точки в другом пуле конечных точек, а не только в пределах одинаковый пул.

Пулы конечных точек настраиваются в порядке приоритета, который при необходимости можно изменить. Этот порядок приоритета учитывается только при использовании Управление трафиком Off - Failover; в противном случае пулы конечных точек будут выбираться на основе критериев, описанных в Методы распределения трафика раздел.

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

Резервный пул (fallback pool) представляет собой пул последней инстанции. Когда все пулы эндпоинтов недоступны или неисправны, для всех запросов и соединений используется резервный пул. Хотя данные монитора состояния всегда учитываются при маршрутизации трафика в балансировщике нагрузки, резервный пул не зависит от этих данных и не подчиняется им.

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

Traffic Steering представляет собой метод переключения между пулами конечных точек. Чтобы разобраться, какой метод Traffic Steering выбрать, см. Типы и методы распределения трафика раздел.

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

Custom rules представляют собой мощный инструмент для настройки маршрутизации и вывода балансировщика нагрузки до того, как запрос или соединение будет отправлено на конечную точку. Например, можно сопоставлять HTTP-метод (например, GET, PUT, POST), чтобы сообщения POST отправлялись в определённый пул конечных точек, предназначенный для приёма информации от клиентов.

Как вариант, TTL привязки сеанса можно сбрасывать при обращении к определённому пути URL, чтобы у клиента было достаточно времени для завершения транзакции.

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

• Поддерживаемые поля и операторы
• Действия балансировки нагрузки

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

Все модели развёртывания Cloudflare Load Balancer обладают встроенной защитой. В следующем разделе кратко описана защита, предоставляемая Cloudflare по умолчанию, а также дополнительные меры защиты, которые можно добавить перед Cloudflare Load Balancers:

• Проксируемый балансировщик нагрузки HTTP уровня 7 (публичный)
  • Защита от DDoS для защиты от атак
  • WAF с управляемый набор правил Cloudflare и Набор правил OWASP для блокировки известных уязвимостей и эксплойтов
• Балансировщик нагрузки DNS-only (Public)
  • Защита DNS от DDoS-атак ↗ чтобы балансировщик нагрузки только для DNS всегда оставался доступным
• Балансировщик нагрузки 4-го уровня Spectrum (Public)
  • DDoS Protection для защиты от атак 4 уровня

Cloudflare предлагает дополнительные уровни защиты, которые можно использовать вместе с балансировкой нагрузки для защиты любых сервисов: сайтов, API, сервисов на базе HTTP(S) и других:

• Проксируемый балансировщик нагрузки HTTP уровня 7 (публичный)
  • Bot management для контроля того, какие боты могут получать доступ к ресурсам
  • WAF для создания пользовательских правил для веб-приложений
  • Client-side security для мониторинга использования скриптов в веб-приложениях
  • API Shield для защиты API
• Балансировщик нагрузки DNS-only (Public)
  • DNSSEC для обеспечения подлинности записей DNS
• Балансировщик нагрузки 4-го уровня Spectrum (Public)
  • IP Access Rules для управления доступом к публичным балансировщикам нагрузки уровня L4

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

Эти балансировщики нагрузки работают в пределах примерно 50 мс от около 95% пользователей интернета, включая конечные точки, что позволяет Cloudflare Load Balancers выполнять как GTM, так и балансировку нагрузки в частной сети. Теперь Cloudflare объединяет эти две ранее раздельные концепции балансировки нагрузки в одном балансировщике. Это помогает организациям направлять трафик в географически релевантные дата-центры, а затем выбирать подходящую конечную точку для обработки запроса.

С помощью Cloudflare Tunnel конечные точки могут находиться в частных сетях и при этом использоваться балансировщиками нагрузки Cloudflare. Cloudflare предлагает публичные балансировщики нагрузки уровня 7, поддерживающие HTTP(S) и WebSocket, а также публичные балансировщики нагрузки уровня 4, способные распределять любой трафик TCP или UDP. Это значит, что Cloudflare может предоставлять услуги балансировки нагрузки любым организациям и пользователям независимо от их местоположения, сценариев использования или имеющейся конфигурации.