Облачная платформаAdvanced

Обзор группы серверов бэкенда

Эта статья полезна?
Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Что такое группа серверов бэкенда?

Группа серверов бэкенда — это логическая коллекция из одного или более серверов бэкенда, предназначенная для одновременного получения большого количества конкурентных запросов. Сервер бэкенда может быть облачным сервером, дополнительным сетевым интерфейсом или IP-адресом.

В следующей таблице описывается, как группа серверов бэкенда работает в процессе перенаправления трафика.

Table 1 Процесс распределения трафика

Шаг 1

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

Шаг 2

Здоровые серверы бэкенда в группе серверов бэкенда получают запрос в соответствии с алгоритмом балансировки нагрузки, обрабатывают запрос и возвращают результат клиенту.

Шаг 3

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

Для выделенных балансировщиков нагрузки тип группы серверов бэкенда может быть Hybrid или IP as a backend server. Вы можете добавить облачные серверы, дополнительные сетевые интерфейсы или IP-адреса в гибридную группу серверов бэкенда. Если установить тип IP as a backend server, можно добавлять только IP-адреса в качестве серверов бэкенда.

Figure 1 показывает архитектуру различных типов групп серверов бэкенда. Подробнее см. Table 2.

Figure 1 Backend server group architecture


Table 2 Типы групп серверов бэкенда

Backend Server Group Type

Backend Server Type

Example

Hybrid

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

Как показано на Figure 1:

  • В группе бэкенд‑серверов A вы можете добавить ECS или дополнительные сетевые интерфейсы в VPC1.
  • В группе бэкенд‑серверов B вы можете добавить IP‑адреса в VPC2 в качестве бэкенд‑серверов.

IP as a backend server

IP‑адреса облачных или локальных серверов, если для балансировщика нагрузки включена функция IP в качестве бэкенда

Как показано на Figure 1, IP‑адреса можно добавить в группу бэкенд‑серверов C в качестве бэкенд‑серверов.

Advantages

Группы бэкенд‑серверов могут предоставить следующие преимущества:

  • Сокращение расходов и упрощённое управление: Вы можете добавлять или удалять бэкенд‑серверы по мере изменения трафика со временем. Это помогает избежать низкой загрузки ресурсов и упрощает управление бэкенд‑серверами.
  • Более высокая надежность: The health check function ensures traffic is routed only to healthy backend servers in the backend server group.

Управление распределением трафика

Вы можете настроить ключевые функции, перечисленные в Table 3, для каждой группы серверов backend, чтобы обеспечить стабильность сервиса.

Table 3 Ключевые функции

Ключевая функция

Описание

Подробности

Режим переадресации

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

Доступны два варианта: Load balancing и Active/Standby.

  • Load balancing: В эту тип группы серверов backend можно добавить несколько серверов backend. Балансировщик нагрузки распределяет запросы между этими серверами backend на основе алгоритма балансировки нагрузки, настроенного для этой группы серверов backend.
  • Active/Standby: После настройки активных и резервных узлов балансировщик нагрузки распределяет трафик на основе результатов проверки состояния активных и резервных узлов. Роли активного и резервного узлов не меняются. Ниже показано, как это работает:
    • Если активный узел здоров, балансировщик нагрузки перенаправляет трафик к активному узлу.
    • Если активный узел нездоров, но резервный узел здоров, новые соединения будут устанавливаться с резервным узлом, а существующие соединения с активным узлом будут разорваны после истечения интервала тайм‑аута.
    • Когда активный узел становится здоровым, новые соединения снова будут устанавливаться с активным узлом, а существующие соединения с резервным узлом будут разорваны после истечения интервала тайм‑аута.

Создание Backend Server Group

Load Balancing Algorithm

Балансировщик нагрузки распределяет входящий трафик между backend servers на основе load balancing algorithm, настроенного для backend server group. Для получения подробной информации о сравнении различных load balancing algorithms см. Table 4.

Настройка алгоритмов балансировки нагрузки для распределения трафика

Sticky Session

Указывает, включена ли опция sticky session. Если вы включите эту опцию, все запросы от одного клиента в течение одной сессии будут отправляться на один и тот же backend server. Для получения подробной информации о сравнении различных типов sticky session см. Table 5.

Включение sticky session для ускорения доступа

Slow Start

Указывает, включён ли slow start. После его включения балансировщик нагрузки линейно увеличивает долю запросов к новым backend servers в backend server group.

Когда длительность slow start истекает, балансировщик нагрузки отправляет полную долю запросов этим backend servers и выходит из режима slow start.

Настройка slow start для Backend Server Group

Table 4 Load balancing algorithms

Load Balancing Algorithm

Описание

Weighted round robin

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

Взвешенный метод наименьшего количества соединений

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

Консистентное хеширование

  • Хеш исходного IP-адреса
  • Идентификатор соединения

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

  • Хеш исходного IP-адреса: вычисляет исходный IP-адрес каждого запроса и направляет запросы с одинаковым исходным IP-адресом к одному и тому же серверу backend.
  • Идентификатор соединения: вычисляет QUIC‑идентификатор соединения и направляет запросы с одинаковым идентификатором к одному и тому же серверу backend.
Таблица 5 Сравнение типов sticky‑session

Тип sticky‑session

Описание

Продолжительность привязки (минуты)

Сценарии, при которых sticky‑session становится недействительным

Исходный IP-адрес

IP-адрес источника каждого запроса вычисляется с использованием алгоритма согласованного хеширования для получения уникального хеш‑ключа, и все серверы backend нумеруются. Система распределяет запросы от клиента на конкретный сервер на основе сгенерированного ключа. Это позволяет запросам от одного и того же IP-адреса перенаправляться на один и тот же сервер backend.

  • Default: 20
  • Maximum: 60
  • Range: 1–60
  • IP-адреса источника клиентов изменились.
  • Продолжительность привязки сессии достигнута.

Load balancer cookie

Load balancer генерирует cookie после получения запроса от клиента. Все последующие запросы с тем же cookie распределяются на один и тот же сервер backend.

  • Default: 20
  • Maximum: 1440, in minutes
  • Range: 1–1440, in minutes
  • Привязка сессий не действует, когда запросы, отправленные клиентами, не содержат cookie.
  • Продолжительность привязки сессии достигнута.

Application cookie

Приложение, развернутое на сервере backend, генерирует cookie после получения первого запроса от клиента. Все последующие запросы с этим cookie направляются на тот же сервер backend.

Группа серверов бэкенда и протоколы слушателя

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

Протокол бэкенда новой группы серверов бэкенда должен соответствовать протоколу фронтенда слушателя, как описано в Table 6.

Table 6Протоколы фронтенда и бэкенда

Спецификация балансировщика нагрузки

Протокол фронтенда

Протокол бэкенда

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

TCP

TCP

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

UDP

  • UDP
  • QUIC

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

TLS

  • TLS
  • TCP

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

HTTP

HTTP

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

HTTPS

  • HTTP
  • HTTPS

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

QUIC

  • HTTP
  • HTTPS

Полезные ссылки