Перейти к содержанию

Горизонтальное масштабирование (кластеризация)

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

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

Масштабирование Webim Chat Backend

Принципиально схема масштабирования бэкенда чата выглядит следующим образом:

Масштабирование (кластеризация) предусматривает запуск избыточного числа экземпляров бэкенда и распределение приходящей нагрузки между ними.

Масштабирование является асимметричным, то есть, нагрузка между серверами распределяется неравномерно. В частности, сложная бизнес-логика на начальном этапе реализуется только на одном из серверов (master); другие серверы выступают в качестве вспомогательных (slave), работают только с данными о работе аккаунта и могут самостоятельно отвечать на некоторые запросы.

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

N.B.

В версиях, вышедших ранее версии 10.5, поддерживается возможность масштабировать нагрузку только на два вспомогательных сервера: один master и один slave. В версиях, вышедших до версии 10.3 (10.2 и ранее) масштабирование не поддерживается.

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

Настройка масштабирования

Для запуска масштабирования на сервере nginx в конфигурационный файл (/etc/nginx/sites-available/webim.conf) необходимо добавить следующее:

location ~ \/l\/o\/set-status  {
       proxy_pass https://127.0.0.1:8270;
       include /etc/nginx/webim-common/python_proxy_params;

       error_page 413 /webim/error-413.json;
}

перед

location ~ \/l\/  {
        proxy_pass https://127.0.0.1:$tornado_port;
        include /etc/nginx/webim-common/python_proxy_params;

        error_page 413 /webim/error-413.json;
}

и

location ~ \/ws\/o\/delta  {
        proxy_http_version 1.1;
        include /etc/nginx/webim-common/python_proxy_params;
           proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "Upgrade";
        proxy_pass https://127.0.0.1:8270;
}

перед

location ~ \/ws\/  {
        proxy_http_version 1.1;
        include /etc/nginx/webim-common/python_proxy_params;
           proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "Upgrade";
        proxy_pass https://127.0.0.1:$tornado_port;
}

Конфигурирование кластера

В параметрах запуска чат-сервера нужно указать

  • --node_name - имя узла. Оно должно содержаться в списке узлов, указываемых в конфигурации кластера. В рамках одного кластера нельзя запускать два узла с указанием одного и того же имени.

  • --cluster_config - путь к json-файлу, содержащему конфигурацию кластера вида:

    {
      "cluster_name": "default",
      "chat_server_node_names": ["master", "slave8270", "slave8271"],
      "chat_server_master_node_name": "master"
    }
    

    Конфигурация содержит:

    • cluster_name - имя кластера

    • chat_server_node_names - список имён всех узлов кластера

    • chat_server_master_node_name - имя выделенного мастер-узла в кластере, выполняющего функции, которые нельзя распределить по разным узлам (например, автоназначение чатов), должно содержаться в списке chat_server_node_names

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

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

  • mq_host (имя хоста RabbitMQ)

  • mq_port (порт подключения к RabbitMQ)

  • mq_username (имя пользователя RabbitMQ)

  • mq_password (пароль пользователя RabbitMQ)

  • mq_virtual_host (значение name созданного виртуального хоста на стороне RabbitMQ)

Актуально для Webim версии 10.3

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

--multinode_mode=master (для master сервера)
--multinode_mode=slave (для slave сервера)

Для удобства администрирования рекомендуется добавить параметр mq_node_id_prefix в дополнительный конфигурационный файл webim_mq.ini, размещающийся в поддиректории /main.ini.d/.

Отключение масштабирования Chat Backend

Для отключения масштабирования Chat Backend необходимо совершить следующие действия:

  1. Выключить все узлы кластера

  2. Убрать из конфигурации nginx настройки, добавленные для включения масштабирования (см. выше)

  3. Запустить Chat Backend без параметров масштабирования