Показать оглавление

Общая информация

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

В статье описаны размещение двух экземпляров Modus BI с одной общей базой метаданных PostgreSQL, настройка маршрутизации Active-Active и основного узла с резервом, а также контроль доступности.

Назначение и область применения

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

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

Архитектура

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

$@startuml skinparam componentStyle rectangle [Пользователи] --> [Единый адрес портала] [Единый адрес портала] --> [Балансировщик Nginx] [Балансировщик Nginx] --> [bi1:3000] [Балансировщик Nginx] --> [bi2:3000] [bi1:3000] --> [Один кластер PostgreSQL\nАдрес: pg:5432\nОбщая база метаданных modusbi] [bi2:3000] --> [Один кластер PostgreSQL\nАдрес: pg:5432\nОбщая база метаданных modusbi] @enduml$

Общая база метаданных содержит служебные объекты портала, включая описания отчётов и настройки доступа. Она отличается от хранилищ аналитических данных, к которым обращаются наборы данных. Подключение к метаданным задаётся в разделе metadata файла modusbi.json, подробнее см. статью « Метаданные Аналитического портала».

Примечание.

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

Режимы маршрутизации

Режим	Работа узлов	Действие при отказе приложения
Active-Active	Оба экземпляра принимают запросы. Nginx распределяет обращения между ними.	После обнаружения недоступности одного экземпляра Nginx направляет новые запросы на другой.
Основной узел и работающий резерв	Основной экземпляр обслуживает запросы. Второй процесс запущен и указан в Nginx с параметром `backup`.	Nginx направляет запросы на резервный экземпляр, когда основной недоступен.
Active-Passive с остановленным резервом	Резервный процесс не запущен.	Для запуска резерва требуется отдельный механизм управления процессами. Параметр `backup` Nginx эту операцию не выполняет.

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

Подготовка

Установите два экземпляра одной версии Modus BI на разных серверах приложения.
Подготовьте одну общую базу метаданных PostgreSQL. Обеспечьте доступ к ней с обоих серверов приложения.
Определите единый адрес портала и настройте сетевую доступность балансировщика, приложений, PostgreSQL и источников данных.
Согласуйте настройки узлов, доступ к используемым файлам, правила авторизации и исключительного выполнения фоновых заданий.
Подготовьте резервные копии и порядок восстановления. Кластеризация не заменяет резервное копирование.

Настройка приложений и PostgreSQL

Подготовьте общую базу метаданных:
```
CREATE DATABASE modusbi;
```
На обоих серверах в файле modusbi.json укажите одну базу modusbi. Параметр application_name различает подключения узлов в диагностике PostgreSQL и не создаёт отдельную базу. Пример строк подключения (замените учётные данные и имя сервера значениями вашей инфраструктуры):
```
Сервер bi1 — metadata.datasource:
postgres://METADATA_USER:METADATA_PASSWORD@pg:5432/modusbi?application_name=modusbi_node1

Сервер bi2 — metadata.datasource:
postgres://METADATA_USER:METADATA_PASSWORD@pg:5432/modusbi?application_name=modusbi_node2
```
Имя pg обозначает сервер PostgreSQL. Параметры TLS задавайте в соответствии с настройками СУБД и требованиями вашей инфраструктуры.
Настройте адреса приложения. Оба экземпляра приложения слушают порт 3000. Браузер направляет запросы API через балансировщик:
```
"server": {
  "host": "0.0.0.0",
  "port": 3000
},
"backend": {
  "protocol": "http",
  "host": "bi.example.org",
  "port": 8080,
  "base_url": "/v1/api/"
}
```
Замените bi.example.org доступным пользователям именем балансировщика. Протокол и порт должны соответствовать его настройкам. Адрес отдельного узла приложения в разделе backend приведёт к обходу балансировки.
Новую пустую базу инициализируйте один раз: запустите приложение на первом сервере с ключом -init из каталога установки. На втором сервере повторную инициализацию этой базы не выполняйте. После завершения инициализации запустите оба приложения без ключа -init. При подключении второго сервера к уже работающему порталу используйте существующую базу без повторной первоначальной инициализации. Перед изменениями сохраните резервную копию. Обновление схемы общей базы выполняйте централизованно по регламенту обновления продукта, без параллельного запуска миграций с двух узлов.

Совместная работа с общей базой

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

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

Настройка Nginx

Active-Active

В блоке http объявите группу из двух серверов:

upstream active_active {
    zone aa 64k;
    server bi1:3000 max_fails=1 fail_timeout=5s;
    server bi2:3000 max_fails=1 fail_timeout=5s;
}

Основной сервер и работающий резерв

upstream active_passive {
    zone ap 64k;
    server bi1:3000 max_fails=1 fail_timeout=5s;
    server bi2:3000 backup;
}

Маршрут запросов

Пример блока server для Active-Active:

server {
    listen 8080;
    location / {
        proxy_pass http://active_active;
        proxy_set_header Host $http_host;
        proxy_connect_timeout 1s;
        proxy_read_timeout 30s;
        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_next_upstream_tries 2;
    }
}

Имена bi1 и bi2 должны разрешаться в адреса серверов приложений. Для режима основного сервера с резервом замените proxy_pass http://active_active на proxy_pass http://active_passive. В примере входной порт балансировщика — 8080.

Проверьте и примените конфигурацию:

nginx -t
nginx -s reload

Параметры Nginx определяют обнаружение неудачных обращений и выбор доступного upstream. Они не задают гарантированное время восстановления всей системы. После разрыва соединения во время записи сначала проверьте результат операции; безусловный повтор уже отправленного запроса способен продублировать изменение, подробнее см. документацию вендора «Upstream Nginx».

Проверка работы и отображение результатов

Проверяйте доступность через обычные действия пользователя: вход, открытие отчёта, применение фильтра и сохранение изменения. Для наблюдения за маршрутизацией используйте вкладку Network браузера и журнал Nginx. Для определения узла обработки включите адрес upstream в журнал доступа Nginx.

Откройте единый адрес портала, например http://bi.example.org:8080.
Проверьте, что API-запросы идут через выбранный адрес балансировщика.
Зафиксируйте результаты контрольных операций и узел обработки.
Остановите службу первого экземпляра приложения средствами операционной системы.
Повторите контрольные операции через тот же адрес. Проверьте авторизацию, сохранность данных и отсутствие повторного выполнения записи.
Запустите службу первого экземпляра и повторите проверку.

Зафиксируйте результаты в протоколе испытаний. Проверка доступности должна включать API, работающее с метаданными: доступный HTML и открытый TCP-порт не означают, что приложение может выполнять пользовательские операции.

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

Эксплуатационные границы конфигурации

Компонент	Условия работы конфигурации
Отказ процесса приложения	Nginx направляет новые запросы на доступный экземпляр после обнаружения отказа. Уже выполнявшаяся операция требует проверки результата.
Авторизация между узлами	Общая база содержит общие данные доступа. Сохранение пользовательской сессии при смене узла проверяется отдельно с учётом настроек и состояния приложений. Закрепление пользователя за узлом само по себе не обеспечивает сохранение сессии при его отказе.
Недоступность общей БД	Оба приложения теряют доступ к метаданным. Переключение между порталами не устраняет отказ общей базы.
Отказ PostgreSQL или Nginx	При размещении каждого из этих компонентов в единственном экземпляре он становится единой точкой отказа. Резервирование приложений не покрывает его недоступность.
Фоновые задания	Маршрутизация `backup` не управляет выполнением заданий. Для режима пассивного узла требуется отдельное управление исполнителями.

Резервирование PostgreSQL и защита от отказа ЦОД

Резервирование PostgreSQL защищает общую базу метаданных. При физической репликации резервный сервер получает WAL основного сервера. Оба приложения должны обращаться к текущему основному серверу через согласованный адрес подключения; переключение СУБД и восстановление соединений организуются отдельно от балансировки порталов, подробнее см. документацию вендора «Резервные серверы PostgreSQL».

Размещение двух приложений с одним сервером PostgreSQL не обеспечивает Disaster Recovery между ЦОД. Для защиты от отказа площадки требуется отдельный проект резервирования всех обязательных компонентов: приложений, кластера СУБД, входного адреса, источников данных и внешних зависимостей.

В проекте DR фиксируются:

RTO: допустимое время восстановления пользовательских операций.
RPO: допустимая потеря последних изменений.
Задержка связи: верхняя допустимая граница RTT и колебаний задержки.
Канал: гарантированная полоса, допустимые потери, резервирование маршрутов и время восстановления связи.
Переключение: обнаружение отказа, выбор активной площадки, исключение одновременной записи из изолированных площадок и возврат нагрузки.

Численные параметры канала и нормативы RPO/RTO устанавливаются для выбранной топологии и нагрузки. Таймауты Nginx из примера не являются нормативами межплощадочной связи. Выбор синхронной или асинхронной репликации влияет на задержку записи и допустимую потерю изменений, подробнее см. документацию вендора «Высокая доступность PostgreSQL».

Modus ETL на платформе 1С

Подробнее о кластеризации в Modus ETL см. раздел «Кластеризация в Modus ETL».

Связи контента

Кластеризация аналитического портала Modus BI - Публичная база знаний Modus