Настройка конфигурации#

Вы можете настроить балансировщик нагрузки под свои цели, отредактировав его конфигурацию. Тип балансировки нагрузки зависит от конкретных задач. Для работы на низком уровне (TCP, UDP) доступна stream-балансировка, для приложений и веб-сервисов — балансировка на уровне приложений (HTTP), а для высокоуровневой маршрутизации реализована DNS-балансировка с помощью GSLB.

По умолчанию в конфигурационном файле балансировщика нагрузки заданы следующие настройки:

  • общие настройки;

  • настройки журналов и формат записей;

  • количество соединений, которые может одновременно обрабатывать один рабочий процесс;

  • настройки HTTP;

  • типы файлов;

  • настройки основного сервера и дополнительные маршруты.

О механизмах балансировки#

В Angie ADC поддерживаются следующие механизмы распределения запросов между серверами:

  • round-robin: запросы распределяются по серверам последовательно (используется по умолчанию).

  • weight: запросы распределяются по серверам учетом веса каждого сервера.

  • ip-hash: сервер выбирается с помощью хэш-функции на основе IP-адреса клиента, что обеспечивает “липкость сессии”.

Также доступны динамические алгоритмы балансировки:

  • least_conn: новый запрос направляется на сервер с минимальным количеством активных соединений (наименее загруженный).

  • least_time: вероятность передачи соединения активному серверу обратно пропорциональна среднему времени его ответа.

  • feedback: механизм балансировки нагрузки по обратной связи (по произвольному параметру из ответа на основной или проверочный запрос).

  • least_bandwidth: балансировка на основе наименьшего потребления полосы пропускания.

  • least_packets: балансировка на основе наименьшего числа пакетов в единицу времени.

Способы балансировки round-robin, weight, least_conn, ip-hash, least_time, least_bandwidth, feedback работают с протоколами HTTP и HTTPS, учитывая особенности HTTP-запросов (заголовки, сеансы, ответные данные).

Для протоколов уровня TCP/UDP, где учитываются параметры соединений и производительность, подходят способы балансировки round-robin, weight, least_conn, ip-hash, least_bandwidth, least_packets, least_time.

Редактирование конфигурации балансировщика нагрузки#

Чтобы отредактировать конфигурацию балансировщика нагрузки, выполните следующие действия:

  1. Откройте консоль Angie ADC.

  2. На вкладке Панель мониторинга выберите виджет балансировщика нагрузки и нажмите на него.

    Откроется экран мониторинга с детальной информацией.

  3. Нажмите кнопку Конфигурация в верхней правой части экрана.

    Откроется конфигурационный файл балансировщика нагрузки.

  4. Внесите необходимые изменения. Примеры настройки см. ниже.

  5. Сохраните файл, нажав кнопку Сохранить.

    Изменения будут применены сразу.

Примеры HTTP-балансировки нагрузки#

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

Базовая настройка#

Самая простая конфигурация для балансировки нагрузки с помощью Angie ADC может выглядеть следующим образом:

http {

    upstream myapp1 {

        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    server {

        listen 80;
        location / {

            proxy_pass http://myapp1;
        }
    }
}

В приведенном примере:

  • Группа серверов myapp1 содержит три сервера srv1, srv2 и srv3.

  • На этих серверах работают три экземпляра одного и того же приложения.

  • Используется метод балансировки round-robin (по умолчанию).

  • Все запросы на порт 80 перенаправляются через группу серверов myapp1.

least_conn#

Балансировка нагрузки по наименее загруженному серверу.

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

Пример конфигурации:

http {

    upstream backend {

        least_conn;

        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }

    server {

        listen 80;
        location / {

            proxy_pass http://backend;
        }
    }
}

В этом примере:

  • Директива least_conn включает метод балансировки нагрузки по наименьшему числу соединений.

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

  • Входящие запросы к серверу проксируются в группу backend.

ip-hash#

Балансировка нагрузки с сохранением сессий.

Методы round-robin и least-conn не гарантируют, что запросы от одного клиента будут обрабатываться одним и тем же сервером. Если важно, чтобы клиент всегда направлялся на один сервер (например, при использовании сессионных данных), можно использовать метод ip-hash.

Пример конфигурации:

upstream myapp1 {

    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

Метод ip-hash гарантирует, что запросы от одного клиента будут попадать на один сервер, если этот сервер доступен.

weight#

Взвешенная балансировка нагрузки.

С помощью директивы weight можно указать, какой сервер должен обрабатывать больше запросов. Этот способ рекомендуется, если серверы имеют разную производительность. По умолчанию вес сервера равен 1.

Пример:

upstream myapp1 {

    server srv1.example.com weight=3;
    server srv2.example.com;
    server srv3.example.com;
}

В этой конфигурации каждые пять запросов будут распределены следующим образом: три запроса попадут на srv1, один запрос — на srv2 и еще один — на srv3.

Метод weight может использоваться в комбинации с методами round-robin и least-conn.

least_time#

Балансировка нагрузки на основе наименьшего времени ответа.

Модуль балансировки нагрузки least_time задает для группы метод балансировки нагрузки, при котором вероятность передачи соединения активному серверу обратно пропорциональна среднему времени его ответа; чем оно меньше, тем больше соединений будет получать сервер.

Когда использовать least_time?

  • Переменная нагрузка: запросы распределяются на серверы, которые обрабатывают их быстрее.

  • Высокая доступность: уменьшается время ожидания для пользователей.

  • Гетерогенные серверы: если серверы имеют разное оборудование или настройки, least_time помогает уравновесить нагрузку.

Пример конфигурации:

http {

    upstream backend {

        least_time header;
        server backend1.example.com;
        server backend2.example.com;
        server backend3.example.com;
    }
    server {

        listen 80;
        location / {

            proxy_pass http://backend;
        }
    }
}

В этом примере least_time header: балансировка основана на времени отклика до получения заголовка ответа от сервера.

feedback#

Балансировка по произвольному параметру из ответа на основной или проверочный запрос.

Модуль балансировки нагрузки feedback Задает в upstream механизм балансировки нагрузки по обратной связи. Он динамически корректирует решения при балансировке, умножая вес каждого проксируемого сервера на среднее значение обратной связи, которое меняется с течением времени в зависимости от значения переменной и подчиняется необязательному условию. По умолчанию параметр factor равен 90.

Пример конфигурации:

upstream backend {

    zone backend 1m;

    feedback $feedback_value factor=80 account=$condition_value;

    server backend1.example.com;
    server backend2.example.com;
}

map $upstream_http_custom_score $feedback_value {

    "high" 100;
    "medium" 75;
    "low" 50;
    default 10;
}

map $upstream_probe $condition_value {

    "high_priority" "1";
    "low_priority" "0";
    default "1";
}

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

Примеры TCP/UDP-балансировки нагрузки#

TCP/UDP-балансировка нагрузки позволяет распределять TCP- или UDP-трафик между несколькими серверами. Это полезно для таких задач, как балансировка баз данных, почтовых серверов или других TCP/UDP-сервисов.

Конфигурация для TCP# 

stream {

    upstream tcp_backend {

        server 192.168.1.10:3306 weight=2;
        server 192.168.1.11:3306;
        server 192.168.1.12:3306;
    }

    server {

        listen 3306;
        proxy_pass tcp_backend;
        proxy_timeout 10s;
        proxy_connect_timeout 5s;
    }
}

В этой конфигурации задана группа серверов, участвующих в балансировке (tcp_backend). Настроен вес для серверов, чтобы более мощный сервер получал больше запросов (weight=2), Сервер слушает входящие соединения на порту 3306 (используется для MySQL). Трафик перенаправляется к группе серверов tcp_backend. Настроены тайм-ауты:

  • максимальное время ожидания ответа от сервера 10s;

  • максимальное время для установления соединения с сервером 5s.

Конфигурация для UDP#

Для приложений, работающих через протокол UDP, конфигурация аналогична, но с настройками для UDP-трафика.

stream {

    upstream udp_backend {

        server 192.168.1.20:53;
        server 192.168.1.21:53;

    }
    server {

        listen 53 udp;
        proxy_pass udp_backend;

        proxy_responses 1;
        proxy_timeout 10s;
    }
}

least_bandwidth#

Балансировка на основе наименьшего потребления полосы пропускания.

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

Пример конфигурации:

stream {

    upstream backend {

        least_bandwidth both factor=80;
        server backend1.example.com:12345;
        server backend2.example.com:12345;
    }
    server {

        listen 12345;
        proxy_pass backend;
    }
}

В этом примере:

  • В директиве least_bandwidth настроен учет как входящей, так и исходящей пропускной способности.

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

  • Для балансировки нагрузки определены два проксируемых сервера.

least_packets#

Балансировка на основе наименьшего числа пакетов в единицу времени.

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

Пример конфигурации:

stream {

    upstream backend {

        least_packets both factor=80;
        server backend1.example.com:12345;
        server backend2.example.com:12345;
    }
    server {

        listen 12345;
        proxy_pass backend;
    }
}

В этом примере:

  • В директиве least_packets настроен учет как входящих, так и исходящих пакетов.

  • Коэффициент сглаживания установлен равным 80, что влияет на то, как быстро среднее значение адаптируется к изменениям скорости пакетов.

  • Определены два проксируемых сервера для балансировки нагрузки.

hash#

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

Поддерживается метод hash (например, по IP или произвольному значению). Если сервер из пула станет недоступным или будет добавлен новый сервер, минимальное количество клиентов перенаправится на другие серверы. Используется для “липких сессий”, когда важно, чтобы запросы от одного клиента всегда обрабатывались одним и тем же сервером.

Пример:

upstream tcp_backend {

    hash $remote_addr consistent;
    server 192.168.1.10:3306;
    server 192.168.1.11:3306;
}

Ограничение IP#

Для защиты можно использовать ограничения IP через allow и deny.

Пример:

server {

    listen 3306;
    allow 192.168.1.0/24;
    deny all;
    proxy_pass tcp_backend;
}

В этом примере разрешена только локальная сеть, остальным доступ запрещен.

Проверка работоспособности серверов#

Angie ADC включает встроенные проверки состояния серверов. Если сервер начинает отвечать с ошибками (например, код 500), Angie ADC временно исключает его из пула доступных серверов.

Настройка проверки работоспособности серверов:

upstream myapp1 {

    server srv1.example.com max_fails=2 fail_timeout=10s;
    server srv2.example.com;
    server srv3.example.com;
}

В этой конфигурации сервер помечается как недоступный после двух неудачных запросов подряд (max_fails=2). Через десять секунд сервер снова проверяется на доступность (fail_timeout=10s). Если он восстановился, запросы снова начинают отправляться на этот сервер.