☰

Конфигурация

tag-icon • tag-icon google-cloud-platform load-balancing google-compute-engine google gcp
Конфигурация

у меня естьрегиональная группа инстанцийс 2 экземплярами, обслуживающими порт 8000, автоматическое масштабирование не включено.

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

Веб-сервер на экземплярах работает под управлением Flask, и обработка каждого запроса займет 1 секунду:

@app.route("/", methods=["GET"])
def main() -> Response:
    sleep(1)
    response = jsonify(
        success=True,
        hostname=gethostname(),
    )
    response.status_code = 200
    response.headers["Access-Control-Allow-Origin"] = "*"
    return response

Я могу подтвердить это поведение, перейдя по публичному IP-адресу глобального балансировщика нагрузки, т.е. получение ответа занимает 1 секунду.

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

  • один запрос займет 1 сек.
  • другой запрос займет 2 секунды

Я пробовал менять Locality load balancing policyна Round-Robin, Least-Requestи Random, но всегда получаю одно и то же поведение.

Правильно ли я понимаю, что Locality load balancing policyречь идет только о том, какой бэкенд будет выбран? Если да, то как настроить политику балансировки нагрузки внутри бэкенда (т.е. группы экземпляров)?

Спасибо

Конфигурация

Группа экземпляров

  • Региональный
  • Форма распределения цели: Равномерная
  • [x] Разрешить перераспределение экземпляров
  • Автомасштабирование включено: мин. 2, макс. 2
  • Сигнал автомасштабирования: балансировка нагрузки HTTP 100%
  • Период инициализации: 60 с
  • Проверка здоровья:
    • Путь: /здоровье
    • Протокол: HTTP
    • Порт: 8000
    • Интервал: 30 сек.
    • Тайм-аут: 30 сек.
    • Здоровый порог: 1
    • Порог нездоровья: 10

Балансировщик нагрузки

  • Внешний интерфейс:
    • Протокол: HTTP
    • IP: хххх
    • Уровень сети: Премиум
    • Время ожидания HTTP keepalive: 610 сек.
  • Правила маршрутизации: Все несоответствующие
  • Внутренние службы:
    • Протокол конечной точки: HTTP
    • Названный порт: веб
    • Время ожидания: 300 секунд
    • Облачный CDN: отключен
    • Ведение журнала: включено (частота выборки: 1)
    • Привязка к сеансу: нет
    • Время ожидания слива соединения: 300 секунд
    • Политика дорожного движения:
      • Политика балансировки локальной нагрузки: циклический перебор
      • Обнаружение выбросов: отключено
    • Политика безопасности бэкэнда: нет
    • Политика безопасности Edge: нет
    • Прокси-сервер с поддержкой идентификации: отключен
  • Режим балансировки: Макс. RPS: 1 (на экземпляр)
  • Вместимость: 100%

Тест

siege \
    --concurrent 1 \
    --time 60s \
    "http://x.x.x.x"

С 2 узлами:

  • concurrent=1: в среднем 1,02 сек.
  • concurrent=2: в среднем 1,66 сек.
  • concurrent=4: в среднем 3,35 сек.
  • concurrent=8: в среднем 5,54 сек.

С 4 узлами:

  • concurrent=1: в среднем 1,02 сек.
  • concurrent=2: в среднем 1,18 сек.
  • concurrent=4: в среднем 2,70 сек.
  • concurrent=8: в среднем 3,83 сек.
  • concurrent=16: в среднем 7,26 сек.

С 8 узлами:

  • concurrent=2: в среднем 1,20 сек.
  • concurrent=4: в среднем 1,85 сек.
  • concurrent=16: в среднем 4,40 сек.
  • concurrent=64: в среднем 14,06 сек.
  • concurrent=128: в среднем 19,04 сек.

Ожидаемое поведение

Я бы предположил такие результаты:

  • 2 узла:
    • concurrent=1: 1 сек
    • concurrent=2: 1 сек
    • concurrent=4: ~2 сек.
    • concurrent=8: ~4 сек.
  • 4 узла:
    • concurrent=1: 1 сек
    • concurrent=2: 1 сек
    • concurrent=4: 1 сек
    • concurrent=8: ~2 сек.
    • concurrent=16: ~4 сек.

Обновление 1

Если я перейду на a Classic proxy network load balancerи отправлю 100 запросов:

  • 56 перейти на vm0
  • 44 перейти на vm1

Вместо этого для HTTP LB:

  • 99 перейти на vm0
  • 1 перейти к vm1

решение1

На основеГлобальный внешний балансировщик нагрузки приложенийGFE (Google Front End) оценивает, какие экземпляры бэкенда имеют возможность принимать запросы. Вы можете просмотреть ссылку, которой поделились, чтобы узнать больше о распределении трафика.

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

Я также нашел этосвязьвопрос со stackoverflow, который может быть полезен при использовании режима балансировки.

Связанный контент