В статье приводится схема протоколов и портов общения между отдельными серверами системы ELMA365. Она же является принципиальной схемой масштабирования и построения отказоустойчивого кластера.
Отдельные узлы сервисов хранения и обработки данных (PostgreSQL, MongoDB, RabbitMQ, Redis, MinIO S3) имеют свои правила масштабирования и построения отказоустойчивой схемы. Подробнее об этом читайте в статье «Системные требования ELMA365 On-Premises Enterprise».
Приложение ELMA365 состоит из множества сервисов в изолированных контейнерах и работает в среде управления Kubernetes.
Список сервисов внутри кластера приложения ELMA365
auth |
Сервис авторизации и управления группами, пользователями и оргструктурой. |
balancer |
Сервис управления мультитенантностью в редакции Private Cloud. |
calculator |
Сервис для расчёта формул в элементах приложений. |
chat |
Сервис приватных и групповых сообщений чатов. |
collector |
Чтение и фильтрация элементов приложений. |
convertik |
Конвертация документов в формат .pdf. |
deploy |
Управление миграциями данных и конфигурации при обновлении платформы. |
diskjockey |
Работа с файлами и директориями. |
docflow |
Работа с листами согласования, ознакомления и документооборотом. |
event-bus |
Сервис отслеживания и обработки событий системы. Работает с шиной событий. |
feeder |
Работа с лентой пользователя и в приложениях, работа с каналами. |
front |
Клиентская часть ELMA365. Статика, стили, скрипты. |
integrations |
Сервис работы с внешними интеграциями и пользовательскими модулями. |
mailer |
Отправка почты из системы. |
main |
Основной API-шлюз, который перенаправляет запросы к другим внутренним сервисам. |
messengers* |
Сервис работы с внешними чатами и линиями. |
notifier* |
Уведомления и работа с веб-сокетами. |
processor |
Управление исполнением бизнес-процессов. |
picasso |
Сервис управления слепками ЭЦП. |
scheduler* |
Сервис расписания, отложенного запуска заданий, учёта рабочего времени. |
settings |
Сервис настроек компаний и пользователей. Для сохранения и получения настроек компаний, а также слияния настроек компании и пользователя – чтобы получить результирующие настройки. |
templater |
Шаблонизатор текста и офисных документов, управление шаблонами. |
vahter |
Единый центр аутентификации системы. |
web-forms |
Управление публичных форм для вставки во внешние веб-страницы. |
widget |
Управление low-code виджетами. Хранение и жизненный цикл. |
worker |
Валидация, компиляция и выполнение пользовательских сценариев на сервере в процессах, виджетах и модулях. |
* — сервис не может работать в нескольких экземплярах.
Отказоустойчивость и масштабирование отдельных сервисов
Микросервисная архитектура ELMA365 Enterprise позволяет гибко масштабировать систему в зависимости от профиля нагрузки.
В поставляемом HELM-пакете можно включить автоматическое масштабирование тех микросервисов, которые могут работать многопоточно. Минимальное и максимальное количество реплик задаётся в файле values-elma365.yaml как глобально для всех сервисов, так и индивидуально для каждого из них. Например, для processor, main и worker можно установить больше реплик, чем для других сервисов.
ELMA365 Standard не имеет возможности автомасштабирования, а микросервисы запускаются в единичном экземпляре.
Когда в кластере подключено несколько серверов, то оркестратор Kubernetes пытается равномерно распределить экземпляры сервисов между серверами. При выходе из строя одного из серверов, оркестратор определяет упавшие сервисы и пересоздает их на оставшихся серверах.
Для функционирования отказоустойчивого кластера ELMA365 требуется минимум три сервера. Между ними производится постоянное взаимодействие и отслеживается жизнеспособность каждого сервера. Сервер может считаться неподключенным, если он недоступен по сети определённое время. Система в кластере продолжит работать, пока есть хотя бы два подключенных сервера.
Задача масштабирования для более высоких нагрузок не решается добавлением серверов в кластер. Это только уменьшит вероятность полного отказа всего сервиса. Для масштабирования следует внести изменения в конфигурацию кластера. Вы можете выявить узкое место в нагрузке на систему и масштабировать отдельный сервис.
Например, сервис исполнения сценариев worker. Он ёмкий по ресурсам, но хорошо работает в нескольких параллельных экземплярах. Если профиль нагрузки в вашей конфигурации активно использует серверные сценарии, то можно установить для этого сервиса свой фактор репликации (больше двух). Тогда оркестратор будет создавать дополнительные экземпляры этого сервиса для более быстрой параллельной обработки исполнения сценариев.
Таким же образом можно управлять параллельными экземплярами исполнения и в других сервисах. Чтобы выявить, какие сервисы следует масштабировать, нужно проводить исследование профиля нагрузки определённой конфигурации в разное время.