Архитектура и системные требования / Масштабирование узлов кластера ELMA365 Enterprise

Масштабирование узлов кластера ELMA365 Enterprise

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

Отдельные узлы сервисов хранения и обработки данных (PostgreSQL, MongoDB, RabbitMQ, Redis, Minio S3) имеют свои правила масштабирования и построения отказоустойчивой схемы. Подробнее об этом читайте в разделе «Отказоустойчивая архитектура серверов» технических требований.

Приложение ELMA365 состоит из множества сервисов в изолированных контейнерах и работает в среде управления Kubernetes (в текущей поставке On-Premises для этого используется реализация MicroK8s).

illustration_3

Список сервисов внутри кластера приложения ELMA365

auth

Сервис авторизации и управления группами, пользователями и оргструктурой.

balancer

Сервис управления мультитенантностью в редакции Private Cloud.

calculator

Сервис для расчёта формул в элементах приложений.

chat

Сервис приватных и групповых сообщений чатов.

collector

Чтение и фильтрация элементов приложений.

convertik

Конвертация документов в формат PDF.

deploy

Управление миграциями данных и конфигурации при обновлении платформы.

diskjockey

Работа с файлами и директориями.

docflow

Работа с листами согласования, ознакомления и документооборотом.

event-bus

Сервис отслеживания и обработки событий системы. Работает с шиной событий.

feeder

Работа с лентой пользователя и в приложениях, работа с каналами.

front

Клиентская часть ELMA365. Статика, стили, скрипты.

integrations

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

mailer

Отправка почты из системы.

main

Основной АПИ-шлюз, который перенаправляет запросы к другим внутренним сервисам.

messengers*

Сервис работы с внешними чатами и линиями.

notifier*

Уведомления и работа с веб-сокетами.

processor

Управление исполнением бизнес-процессов.

picasso

Сервис управления слепками ЭЦП.

scheduler*

Сервис расписания, отложенного запуска заданий, учёта рабочего времени.

settings

Сервис настроек компаний и пользователей. Для сохранения и получения настроек компаний, а также слияния настроек компании и пользователя – чтобы получить результирующие настройки.

templater

Шаблонизатор текста и офисных документов, управление шаблонами.

vahter

Единый центр аутентификации системы.

web-forms

Управление публичных форм для вставки во внешние веб страницы.

widget

Управление low-code виджетами. Хранение и жизненный цикл.

worker

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

* - сервис не может работать в нескольких экземплярах.

Отказоустойчивость и масштабирование отдельных сервисов

Распределённая сервисная архитектура позволяет масштабировать решение более гибко, в зависимости от профиля нагрузки на систему. По умолчанию все сервисы кластера (кроме scheduler, notifier, messengers) в кластере Enterprise выполняются в 2-х экземплярах (в Standard в единичном экземпляре). Когда в кластере подключено несколько серверов, то оркестратор microk8s пытается равномерно распределить экземпляры сервисов между серверами. При выходе из строя одного из серверов, оркестратор определяет упавшие сервисы и пересоздает их на оставшихся серверах.

 

Для функционирования отказоустойчивого кластера ELMA365 требуется минимум 3 сервера. Между ними производится постоянное взаимодействие и отслеживается жизнеспособность каждого сервера. Кластер может посчитать сервер “мёртвым”, если он недоступен по сети определённое время. Таким образом вся система в кластере продолжит работать пока есть хотя бы 2 (два) рабочих сервера.

 

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

 

Однако, часто можно выявить определённое узкое место в нагрузке на систему и масштабировать только этот отдельный сервис. Например, сервис исполнения сценариев worker. Он является довольно ёмким по ресурсам и при этом очень хорошо работает в нескольких параллельных экземплярах. И если профиль нагрузки в вашей конфигурации активно использует серверные сценарии, то можно установить для этого сервиса свой фактор репликации (больше 2). Тогда оркестратор будет создавать дополнительные экземпляры этого сервиса для более быстрой параллельной обработки исполнения сценариев.

 

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

Нашли опечатку? Выделите текст, нажмите ctrl + enter и оповестите нас