Введение
Ниже представлены минимальные требования к техническому и программному обеспечению для успешного запуска и использования Comindware Platform.
Важно!
Приведённые здесь требования и рекомендации соответствуют минимальной конфигурации для запуска и опытно-промышленной эксплуатации (ОПЭ) одного приложения на основе Comindware Platform.
Эта конфигурация может оказаться недостаточной для промышленной эксплуатации приложений, разработанных на основе Comindware Platform.
Перед вводом приложений на основе Comindware Platform в промышленную эксплуатациею конечный пользователь (см. определения в Лицензионном соглашении конечного пользователя программного обеспечения Comindware) должен самостоятельно выполнить следующие шаги:
- определить уровень критичности бизнес-функций системы и соответствующие параметры:
- требуемый уровень доступности (high availability);
- степень толерантности к всплескам нагрузки (способность системы выдерживать резкий рост нагрузки без деградации производительности);
- стратегию внесения изменений при обновлении и модификации системы в процессе эксплуатации.
- целевые параметры производительности, которые система должна обеспечивать в промышленной эксплуатации (время отклика, пропускная способность, использование ресурсов и другие показатели).
- провести нагрузочное тестирование своих приложений и оптимизацию прикладного решения на основе Comindware Platform, чтобы определить достаточную, работоспособную, надёжную и устойчивую конфигурацию, удовлетворяющую требованиям конечного пользователя. См. «Нагрузочное тестирование».
В ходе промышленной эксплуатации рекомендуется регулярно по результатам уточнения требований, развития решения и нагрузочного тестирования проводить оптимизацию архитектуры, конфигурации, ландшафта и выделенных ресурсов.
Comindware оставляет за собой право требовать пересмотра конфигураций после выпуска новых версий программного обеспечения, как минимум раз в год. См. «Ежегодный пересмотр конфигурации».
Доступность системы в минимальной конфигурации
Если для конкретного бизнес-сценария допустимы кратковременные простои системы на основе Comindware Platform, это определяет соответствующие требования к ресурсам.
В таких случаях можно рассмотреть использование минимальной конфигурации, но при этом конечный пользователь принимает на себя все риски того, что не гарантируется непрерывная доступность системы и она может периодически быть недоступна.
Требования к техническому обеспечению
Сервер базы данных и приложений
| Характеристика | До 500 пользователей и до 10 000 процессов в месяц | До 5000 пользователей и до 50 000 процессов в месяц | Расширение на каждые 4000 пользователей и 30 000 процессов в месяц |
|---|---|---|---|
| Процессор | 8 ядер от 3,7 ГГц | 8 ядер от 3,7 ГГц | + 8 ядер от 3,7 ГГц |
| Память | 32 ГБ | 64 ГБ | + 32 ГБ |
| Дисковый накопитель | SSD (200 ГБ) + HDD для прикрепляемых файлов | SSD (200 ГБ) + HDD для прикрепляемых файлов | SSD (200 ГБ) + HDD для прикрепляемых файлов |
| Сетевое соединение | 1 ГБит/с | 10 ГБит/с |
Примечание
Для обеспечения оптимальной производительности следует использовать SSD-накопители с интерфейсом NVMe.
Клиентское рабочее место
| Характеристика | Значение |
|---|---|
| Процессор | x86 или x64 совместимый процессор |
| Память | 8 ГБ |
| Монитор | 1024x768 и выше |
| Сетевое соединение | 10 Мбит/с |
Требования к программному обеспечению
Сервер баз данных и приложений
| Характеристика | Windows | Linux |
|---|---|---|
| ОС | Windows Server Standard 2022 |
|
| СУБД | Apache Ignite | Apache Ignite |
| Веб-сервер | Internet Information Services (IIS) 10 и выше | NGINX 1.24 и выше |
| Дополнительное ПО (поставляется и устанавливается вместе с основным пакетом) |
|
|
Клиентское рабочее место
| Характеристика | Значение |
|---|---|
| ОС | Linux или Windows |
| Веб-браузер | Последние публичные версии Google Chrome, Mozilla Firefox и Microsoft Edge |
| Дополнительное ПО | Для открытия соответствующих файлов, скачиваемых из системы |
Методология расчёта необходимых ресурсов и жизненный цикл конфигурации ПО
Конфигурации для различных этапов разработки и эксплуатации ПО
Жизненный цикл приложений на основе Comindware Platform включает следующие этапы:
- Разработка
- Тестирование
- Опытно-промышленная эксплуатация (ОПЭ)
- Нагрузочное тестирование
- Промышленная эксплуатация
- Ежегодный пересмотр конфигурации
Для каждого этапа жизненного цикла приложений на основе Comindware Platform рекомендуется развёрнуть отдельные стенды с ПО Comindware Platform
Совет
Рекомендуется развернуть как минимум два стенда: со стабильной версией приложений на основе Comindware Platform и версией для разработки.
Это обеспечит возможность параллельной работы стабильной версии приложений в промышленной эксплуатации и версий для разработки и тестирования новых функций.
Нагрузочное тестирование
После завершения опытно-промышленной эксплуатации конечный пользователь должен самостоятельно провести нагрузочное тестирование своих приложений на основе Comindware Platform.
Целью нагрузочного тестирования является определение следующих конфигураций:
- достаточной для достижения требуемой производительности;
- работоспособной, обеспечивающей стабильную работу приложений;
- надёжной, обеспечивающей отказоустойчивость системы;
- устойчивой, способной выдерживать пиковые нагрузки.
На основе результатов нагрузочного тестирования определяется конфигурация ПО и оборудования для промышленной эксплуатации в соответствии с бизнес-требованиями и уровнем критичности бизнес-функций, выполняемых приложениями на основе Comindware Platform.
Ежегодный пересмотр конфигурации
Даже если приложения успешно работали в некоторой конфигурации программного и технического обеспечения, Comindware оставляет за собой право требовать пересмотра конфигурации после выпуска новых версий ПО Comindware Platform и стороннего ПО. Минимальная частота пересмотра конфигурации — один раз в год.
При выходе новых версий Comindware Platform минимальные требования к системным ресурсам могут изменяться.
Конечный пользователь должен быть готов к необходимости обновления конфигурации программного и технического обеспечения при обновлении версии Comindware Platform.
Примеры расчёта необходимого технического обеспечения
Здесь представлены рекомендации по определению характеристик технического обеспечения для развёртывания Comindware Platform.
Используйте собственные фактические параметры для расчётов
При расчёте и выделении необходимого объёма аппаратных ресурсов, программного и технического обеспечения вы должны руководствоваться своими фактическими бизнес-потребностями.
Здесь представлены лишь примерные рекомендации, которые необходимо адаптировать для ваших конкретных приложений и окружения.
Приведённые ниже сведения даны исключительно в справочных целях в качестве ориентира и отправной точки для фактических прикладных расчётов.
Конфигурация серверов приложений
Сервер приложений размещается на физической или виртуальной машине.
Сервер приложений обеспечивает взаимодействие Comindware Platform с пользователями, сторонними системами, ввод, обработку и хранение данных (таких как файлы базы данных, файлы конфигурации, загружаемые пользователями файлы, файлы журналов, файлы резервных копий).
Следующие рекомендации позволят определить необходимую конфигурацию технического обеспечения для работы серверов приложений.
В минимальной конфигурации достаточно развернуть один сервер приложений для разработки, тестирования и опытно-промышленной эксплуатации приложений.
Приведенные ниже параметры носят рекомендательный характер. Их следует адаптировать для конкретных приложений на основе Comindware Platform с учётом ваших фактических бизнес-потребностей и результатов нагрузочного тестирования.
Фактические требования к техническому обеспечению могут значительно отличаться и зависят от следующих факторов:
- количества активных пользователей в Системе;
- количества приложений в Системе;
- количества запускаемых процессов;
- количества настроенных вычислений, правил, условий и зависимостей данных;
- объема хранимой информации и документов.
Подсистемы, виртуальные сервисы и виртуальные машины с ПО рекомендуется размещать на нескольких физических машинах.
Каналы связи между узлами системы должны обеспечивать пропускную способность не менее 10 Гбит/с.
Методика расчета требуемых аппаратных ресурсов
Здесь представлены примеры расчёта системных ресурсов в конфигурации системы для следующего количества пользователей:
- 500 зарегистрированных;
- 200 активных;
- 25 постоянных.
Инфраструктурные сервисы
- Виртуальные серверы одного сервиса должны быть размещены на разных физических серверах.
- Скорость соединения между серверами должна быть не менее 10 Гбит/с.
- SSD-накопитель для базы данных должен быть высокоскоростным и высоконадёжным.
| Логич. ядер ЦП от 3,7 ГГц | ОЗУ, ГБ | Раздел с ПО, ГБ, SSD | БД, ГБ, SSD | |||
|---|---|---|---|---|---|---|
Обратные прокси (VPS): Reverse proxy1, Reverse proxy2
|
||||||
| 2 | 2 | 24 | ||||
Система мониторинга и отслеживания (VPS): Monitor1, Monitor2
|
||||||
| 2 | 4 | 24 | 128 | |||
Продуктовый ландшафт
- Виртуальные серверы одного сервиса должны быть размещены на разных физических серверах.
- Скорость соединения между серверами должна быть не менее 10 Гбит/с.
- SSD-накопитель для базы данных должен быть высокоскоростным и высоконадёжным.
| Логич. ядер ЦП от 3,7 ГГц | ОЗУ, ГБ | Раздел с ПО, ГБ, SSD | БД, ГБ, SSD | Загружаемые файлы, ГБ, СХД HDD |
Журналы, HDD | Резервные копии, ГБ, СХД HDD |
|
|---|---|---|---|---|---|---|---|
Серверы приложений (VPS): CBAP-node1, CBAP-node2, CBAP-node3
|
|||||||
| 8 | 32 | 64 | 128 | 1024 | 16 | 512 | |
Сервер журналов OpenSearch (VPS): OpenSearch-node1, OpenSearch-node2, OpenSearch-node3
|
|||||||
| 4 | 16 | 24 | 128 | 16 | 512 | ||
Ландшафт тестирования и разработки
- SSD-накопитель для базы данных должен быть высокоскоростным и высоконадёжным.
| Логич. ядер ЦП от 3,7 ГГц | ОЗУ, ГБ | Раздел с ПО, ГБ, SSD | БД, ГБ, SSD | Загружаемые файлы, ГБ, СХД HDD |
Журналы, HDD | Резервные копии, ГБ, СХД HDD |
|---|---|---|---|---|---|---|
GitServer: 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 |
Сервер журналирования транзакций (VPS): OpenSearch
|
||||||
| 4 | 16 | 24 | 128 | 16 | 128 | |
Минимальная конфигурация основного сервера приложений
| Кол-во польз. | ЦП | ОЗУ | HDD | SSD |
|---|---|---|---|---|
| 1–200 активных | 8 ядер от 3,7 ГГц + (1 ядро × 100 акт. польз. × кол-во прил.) |
32 ГБ + (4 ГБ × 100 акт. польз. × кол-во прил.) |
16 ГБ | 16 ГБ |
| 200 активных | 8 ядер + (2 ядра × кол-во прил.) |
32 ГБ + (8 ГБ × кол-во прил.) |
200 ГБ × кол-во прил. | 200 ГБ × кол-во прил. |
| 300 активных | 8 ядер + (3 ядра × кол-во прил.) |
32 ГБ + (12 ГБ × кол-во прил.) |
200 ГБ × кол-во прил. | 200 ГБ × кол-во прил. |
| 400 активных | 8 ядер + (4 ядра × кол-во прил.) |
32 ГБ + (16 ГБ × кол-во прил.) |
200 ГБ × кол-во прил. | 200 ГБ × кол-во прил. |
Минимальная конфигурация резервного сервера приложений
| Кол-во польз. | ЦП | ОЗУ | HDD | SSD |
|---|---|---|---|---|
| 1–200 | 8 ядер от 3,7 ГГц + (1 ядро × 100 польз. × кол-во прил.) |
32 ГБ + (4 ГБ × 100 польз. × кол-во прил.) |
200 ГБ × кол-во прил. | 8 ГБ × кол-во прил. |
| 200 | 8 ядер + (2 ядра × кол-во прил.) |
32 ГБ + (8 ГБ × кол-во прил.) |
200 ГБ × кол-во прил. | 8 ГБ × кол-во прил. |
| 300 | 8 ядер + (3 ядра × кол-во прил.) |
32 ГБ + (12 ГБ × кол-во прил.) |
200 ГБ × кол-во прил. | 8 ГБ × кол-во прил. |
| 400 | 8 ядер + (4 ядра × кол-во прил.) |
32 ГБ + (16 ГБ × кол-во прил.) |
200 ГБ × кол-во прил. | 200 ГБ × кол-во прил. |
Минимальная конфигурация серверов разработки и тестирования
| Кол-во польз. | ЦП | ОЗУ | HDD | SSD |
|---|---|---|---|---|
| 1–100 | 8 ядер от 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 (нагрузка при хранении и обработке временных файлов может возрастать при большом количестве активных пользователей и транзакций, загрузке пользователями множества файлов и под влиянием прочих факторов).