Развертывание Comindware Business Application Platform. Архитектура, ландшафт, программное и техническое обеспечение
Введение
Продукт Comindware Business Application Platform представляет собой целостный программный комплекс на базе стека современных технологий.
В настоящем руководстве представлено краткое описание архитектуры Comindware Business Application Platform, а также даны рекомендации по выбору ландшафта и конфигурации программного и аппаратного обеспечения для развертывания системы на основе Comindware Business Application Platform.
Определения
- Сервер приложений — установленный экземпляр ПО Comindware Business Application Platform.
- Приложение — обособленное бизнес-решение, реализованное на сервере приложений.
- Активные пользователи — пользователи, регулярно генерирующие данные на сервере приложений.
- DAS — запоминающее устройство, непосредственно подключенное к серверу приложений.
- SAN — сетевая система хранения (СХД, сеть хранения данных).
- IOPS — количество операций ввода-вывода в секунду.
Архитектура Системы
В основе Системы лежит клиент-серверная компонентно-многослойная сервисно-ориентированная архитектура, расширяемая плагинами и адаптерами.
В состав Системы входят перечисленные ниже подсистемы.
- Веб-приложение: одностраничное приложение (SPA) на основе Marionette, Backbone, React, Redux.
- Мобильное приложение: React Native on Expo.
- Бэкенд: компоненты-сервисы на основе .NET 6.0, .NET Framework 4.8 (Windows), Mono 6.12 (Linux), JDK 17.
- СУБД: фирменная патентованная СУБД Comindware Elastic Data, с хранением данных в Apache Ignite.
- Подсистема полнотекстового поиска: Lucene.Net.
- Подсистема сбора и анализа журналов транзакционных данных и данных мониторинга Системы: Elasticsearch, Kibana.
- Подсистема файловых журналов: NLog.
- Модули для интеграции: см. параграф «Интеграция с внешними системами».
Полный перечень стороннего ПО, входящего в состав и необходимого для работы Системы, см. в статьях: Comindware Business Application Platform 4.7 Перечень стороннего программного обеспечения для Linux.
Безопасность и отказоустойчивость Системы
В Системе предусмотрены перечисленные ниже механизмы обеспечения безопасности и отказоустойчивости.
- Внешняя безопасность — реализуется посредством:
- механизма аутентификации пользователей Kerberos и OpenID;
- сетевого экрана;
- обратного прокси-сервера.
- Внутренняя безопасность — реализуется посредством ролевой модели безопасности.
- Отказоустойчивость — реализуется посредством использованием резервных серверов и дополнительных узлов хранения и обработки данных.
- Масштабируемость — реализуется посредством увеличения количества серверов, обрабатывающих запросы.
См. «Безопасность».
Интеграция с внешними системами
В Системе предусмотрены перечисленные ниже механизмы интеграции с внешними системами.
- Git —контроль версий приложений, создаваемых с помощью Системы.
- OData — обмен данными с внешними системами посредством REST API.
- OpenLDAP (Active Directory) — аутентификация, управление аккаунтами и единый вход.
- SMTP/IMAP/Exchange — получение и отправка электронных писем.
- ESB (RabbitMQ / MSMQ) — обмен сообщениями с внешними системами в распределенных и федеративных конфигурациях.
См. «Подключения».
Ландшафт развертывания Системы
Для обеспечения бесперебойной работы Систему необходимо развернуть в окружении, обеспечивающем достаточную производительность и отказоустойчивость.
Систему можно развернуть для доступа через интернет и интранет:
- в минимальной конфигурации — на одной виртуальной или физической машине заказчика.
- в продуктовой конфигурации— на мощностях заказчика в отказоустойчивой конфигурации в соответствии с требованиями заказчика.
Рекомендуемые варианты развертывания Системы
Минимальная конфигурация
Ниже перечислены компоненты типовой минимальной конфигурации Системы, предназначенной для демонстраций и реализации пилотных проектов.
- Comindware Business Application Platform: установленный экземпляр ПО.
- СУБД Comindware Elastic Data.
- Сервер Elasticsearch — в конфигурации с одним узлом.
Продуктовая конфигурация
Ниже перечислены компоненты типовой продуктовой конфигурации, обеспечивающей дублирование и резервирование ресурсов, а также отказоустойчивость Системы.
- Comindware Business Application Platform: установленный экземпляр ПО.
- СУБД Comindware Elastic Data.
- Сервер Elasticsearch.
- Обратный прокси-сервер NGINX для фильтрации нежелательных запросов и ретрансляции допустимых запросов во внутреннюю сеть.
- Сервер Zabbix для мониторинга доступности служб и свободного пространства на дисках.
- Почтовый сервер (SMTP/IMAP) (необязательно) для передачи уведомлений.
- Сервер LDAP (необязательно) для централизованного управления инфраструктурой сети.
- Сервер Git (необязательно) для контроля версий приложений, создаваемых с помощью Comindware Business Application Platform.
Продуктовое использование накладывает требования на следующие характеристики Системы:
- безопасность — реализуется за счет настройки сетевого экрана и обратного прокси-сервера;
- отказоустойчивость — реализуется за счет использования резервных серверов и дополнительных узлов на серверах, хранящих данные;
- масштабируемость — реализуется за счет добавления дополнительных серверов, обрабатывающих запросы.
Рекомендуемый набор серверов приложений
Для повышения эффективности разработки и тестирования приложений, а также отказоустойчивости и безопасности эксплуатации приложений рекомендуется развернуть несколько серверов приложений (необходимость использования каждого из этих серверов определяется при составлении технических требований):
- сервер разработки (development), на котором осуществляется разработка приложений;
- сервер тестирования (pre-production), на котором осуществляется тестирование приложений;
- основной сервер (production), на котором осуществляется эксплуатация приложений;
- резервный сервер (standby), который используется в случае перегрузки или выхода из строя основного сервера.
Техническое обеспечение Системы
В данной статье представлены рекомендуемые характеристики технического обеспечения для развёртывания Системы на мощностях заказчика под управлением операционной системы Windows или Linux.
Конфигурация серверов приложений
Сервер приложений размещается на физической или виртуальной машине, обеспечивая взаимодействие с пользователями, сторонними системами, ввод, обработку и хранение таких данных, как файлы базы данных, файлы конфигурации, загружаемые пользователями файлы, файлы журналов, файлы резервных копий.
Следующие рекомендации позволят определить необходимую конфигурацию технического обеспечения для работы серверов приложений.
В минимальной конфигурации достаточно развернуть один сервер приложений для разработки, тестирования и эксплуатации приложений.
Приведенные ниже требования носят рекомендательный характер и позволяют обеспечить комфортную работу конечных пользователей, гражданских разработчиков и тестировщиков приложений Comindware Business Application Platform.
Фактические требования к техническому обеспечению могут значительно отличаться и зависят от следующих факторов:
- количества активных пользователей в Системе;
- количества приложений в Системе;
- количества запускаемых процессов;
- количества настроенных вычислений, правил, условий и зависимостей данных;
- объема хранимой информации и документов.
Подсистемы (см. параграф «Конфигурация подсистем») и виртуальные машины с ПО рекомендуется размещать на нескольких физических машинах.
Каналы связи между узлами Системы должны обеспечивать пропускную способность не менее 10 Гбит/с.
Примеры расчёта системных ресурсов отказоустойчивой системы
В следующих таблицах представлена конфигурация системы для следующего количества пользователей:
- 500 зарегистрированных;
- 200 активных;
- 25 постоянных.
Инфраструктурные сервисы
- Виртуальные серверы одного сервиса должны быть размещены на разных физических серверах.
- Скорость соединения между серверами должна быть не менее 10 Гб/с.
- SSD-накопитель для базы данных должен быть высокоскоростным и высоконадёжным.
| Логич. ядер ЦП от 3,0 ГГц | ОЗУ, ГБ | Раздел с ПО, ГБ, SSD | БД, ГБ, SSD | |||
|---|---|---|---|---|---|---|
Обратные прокси (VPS): NGINX reverse proxy1, NGINX reverse proxy2 |
||||||
| 2 | 2 | 24 | ||||
Система мониторинга и отслеживания (VPS): Zabbix1, Zabbix2 |
||||||
| 2 | 4 | 24 | 128 | |||
Продуктовый ландшафт
- Виртуальные серверы одного сервиса должны быть размещены на разных физических серверах.
- Скорость соединения между серверами должна быть не менее 10 Гб/с.
- SSD-накопитель для базы данных должен быть высокоскоростным и высоконадёжным.
| Логич. ядер ЦП от 3,0 ГГц | ОЗУ, ГБ | Раздел с ПО, ГБ, SSD | БД, ГБ, SSD | Загружаемые файлы, ГБ, СХД HDD | Журналы, HDD | Резервные копии, ГБ, СХД HDD | |
|---|---|---|---|---|---|---|---|
Серверы приложений (VPS): CBAP-node1, CBAP-node2, CBAP-node3 |
|||||||
| 8 | 32 | 64 | 128 | 1024 | 16 | 512 | |
Сервер журналов Elasticsearch (VPS): Elasticsearch-node1, Elasticsearch-node2, Elasticsearch-node3 |
|||||||
| 4 | 16 | 24 | 128 | 16 | 512 | ||
Ландшафт тестирования и разработки
- SSD-накопитель для базы данных должен быть высокоскоростным и высоконадёжным.
| Логич. ядер ЦП от 3,0 ГГц | ОЗУ, ГБ | Раздел с ПО, ГБ, SSD | БД, ГБ, SSD | Загружаемые файлы, ГБ, СХД HDD | Журналы, HDD | Резервные копии, ГБ, СХД HDD |
|---|---|---|---|---|---|---|
GitLab: git-server |
||||||
| 2 | 4 | 24 | 128 | |||
Сервер приложений (VPS): CBAP-test |
||||||
| 8 | 24 | 64 | 128 | 32 | 16 | 128 |
Сервер приложений (VPS): CBAP-dev |
||||||
| 8 | 24 | 64 | 128 | 32 | 16 | 128 |
Сервер журналов Elasticsearch (VPS): Elasticsearch |
||||||
| 4 | 16 | 24 | 128 | 16 | 128 | |
Минимальная конфигурация основного сервера приложений
| Кол-во польз. | ЦП | ОЗУ | HDD | SSD |
|---|---|---|---|---|
| 1–200 активных | 4 ядра от 3,7 ГГц + (1 ядро × 100 акт. польз. × кол-во прил.) |
16 ГБ + (4 ГБ × 100 акт. польз. × кол-во прил.) |
16 ГБ | 16 ГБ |
| 200 активных | 4 ядра + (2 ядра × кол-во прил.) |
16 ГБ + (8 ГБ × кол-во прил.) |
16 ГБ × кол-во прил. | 16 ГБ × кол-во прил. |
| 300 активных | 4 ядра + (3 ядра × кол-во прил.) |
16 ГБ + (12 ГБ × кол-во прил.) |
16 ГБ × кол-во прил. | 16 ГБ × кол-во прил. |
| 400 активных | 4 ядра + (4 ядра × кол-во прил.) |
16 ГБ + (16 ГБ × кол-во прил.) |
16 ГБ × кол-во прил. | 16 ГБ × кол-во прил. |
Минимальная конфигурация резервного сервера приложений
| Кол-во польз. | ЦП | ОЗУ | HDD | SSD |
|---|---|---|---|---|
| 1–200 | 4 ядра от 3,7 ГГц + (1 ядро × 100 польз. × кол-во прил.) |
16 ГБ + (4 ГБ × 100 польз. × кол-во прил.) |
16 ГБ × кол-во прил. | 8 ГБ × кол-во прил. |
| 200 | 4 ядра + (2 ядра × кол-во прил.) |
16 ГБ + (8 ГБ × кол-во прил.) |
16 ГБ × кол-во прил. | 8 ГБ × кол-во прил. |
| 300 | 4 ядра + (3 ядра × кол-во прил.) |
16 ГБ + (12 ГБ × кол-во прил.) |
16 ГБ × кол-во прил. | 8 ГБ × кол-во прил. |
| 400 | 4 ядра + (4 ядра × кол-во прил.) |
16 ГБ + (16 ГБ × кол-во прил.) |
16 ГБ × кол-во прил. | 16 ГБ × кол-во прил. |
Минимальная конфигурация серверов разработки и тестирования
| Кол-во польз. | ЦП | ОЗУ | HDD | SSD |
|---|---|---|---|---|
| 1–100 | 4 ядра от 3,7 ГГц | 16 ГБ | 16 ГБ | 16 ГБ |
Конфигурация системы хранения данных
В минимальной конфигурации все папки данных сервера приложений могут храниться в одном разделе на высокопроизводительном SSD-накопителе.
Высокопроизводительные системы хранения (SSD DAS/SAN) должны обеспечивать производительность не меньше 100 000 IOPS на 1 сервер приложений.
Объем выделяемого пространства на высокопроизводительных (SSD DAS/SAN) и низкопроизводительных системах хранения (HDD DAS/SAN) следует определить в ходе составления технических требований.
Для оптимизации обработки, хранения и резервного копирования папки данных сервера приложений можно разместить в отдельных хранилищах:
- файлы базы данных и конфигурации — SSD DAS/SAN (эти данные сервер приложений обрабатывает постоянно в оперативном режиме, что создает высокую нагрузку на подсистему хранения);
- загруженные пользователями файлы — HDD DAS/SAN (такие файлы хранятся долговременно, не в базе данных и запрашиваются по ссылке, поэтому для их обработки и хранения высокопроизводительная подсистема хранения не требуется);
- журнал Системы — HDD DAS/SAN (запись файлов журнала создает минимальную нагрузку на подсистему хранения);
- резервные копии — HDD DAS/SAN (резервные копии формируются периодически, используются редко, для их хранения важнее объем, а не производительность хранилища; тем не менее, скорость резервного копирования может снижаться в случае наличия большого количества мелких файлов, загруженных пользователями, в таком случае можно разместить папку резервных копий на высокопроизводительном накопителе);
- временная папка — SSD DAS/SAN (нагрузка при хранении и обработке временных файлов может возрастать при большом количестве активных пользователей и транзакций, загрузке пользователями множества файлов и под влиянием прочих факторов).
Конфигурация подсистем
Конфигурация сервера Apache Ignite
Apache Ignite в минимально необходимой конфигурации устанавливается автоматически при развертывании Comindware Business Application Platform.
Требования к конфигурации
См. статью Apache Ignite. Установка и настройка. Краткое руководство.
Примеры конфигураций
См. статью Apache Ignite. Установка и настройка. Краткое руководство.
Конфигурация сервера Elasticsearch
Elasticsearch в минимально необходимой конфигурации устанавливается автоматически при развертывании Comindware Business Application Platform.
Требования к конфигурации
- Должна быть включена аутентификация.
- Должна быть разрешена работа под любым аккаунтом, кроме стандартного:
elastic. - Номер порта должен отличаться от стандартного 9200.
- В конфигурации должно быть задано достаточное количество шардов: минимум 3000.
Примеры конфигураций
- Развертывание одного узла в Windows: см. Установка Elasticsearch. Краткое руководство для Windows.
- Развертывание кластера в Linux: см. Установка Elasticsearch и настройка кластера Elasticsearch без сертификатов подлинности.
Конфигурация обратного прокси-сервера
NGINX в минимально необходимой конфигурации устанавливается автоматически при развертывании Comindware Business Application Platform.
Требования к конфигурации
- Сервер NGINX;
- Модуль ModSecurity;
- Модуль GeoIP.
Примеры конфигураций
- Развертывание сервера NGINX: cм. «NGINX. Установка и настройка».
- Развертывание модуля GeoIP: см. «Модуль GeoIP для NGINX. Установка и настройка».
Конфигурация сервера Zabbix
Требования к конфигурации
Конфигурация сервера Zabbix должна обеспечивать мониторинг работоспособности Системы, как указано ниже.
- Мониторинг доступности сервера Apache Ignite
- Сервер может быть недоступен из-за проблем с сетью.
- На сервере может закончиться свободное место на диске.
- Конфигурация сервера может не позволять обработать запросы, например, ввиду невозможности создания нового индекса или соответствующего ему шарду.
- Мониторинг доступности сервера Elasticsearch
- Сервер может быть недоступен из-за проблем с сетью.
- На сервере может закончиться свободное место на диске.
- Конфигурация сервера может не позволять обработать запросы, например, ввиду невозможности создания нового индекса или соответствующего ему шарда.
- Мониторинг места на дисках с базой данных, журналами, резервными копиями и т. п.
- Мониторинг ошибок в процессе работы Системы
- Ошибки конфигурации Системы.
- Ошибки в процессе эксплуатации Системы.
- Ошибки, связанные с обновлением окружения, в котором работает Система, или компонентов самой Системы.
Примеры конфигураций
См. статью «Zabbix. Установка и настройка. Краткое руководство».
Эта статья была полезна 6 чел.
