Масштабируемость и производительность
Рекомендации к аппаратным ресурсам
В разделе даны рекомендации по применению аппаратных и программных сред для работы серверных компонент платформы.
Требования к вычислительным ресурсам в основном определяется 2 основными показателями:
- скорость потока поступающих измерений;
- количество сессий пользователей.
Первый показатель - скорость потока, влияет на производительность серверной обработки.
Второй показатель - количество сессий пользователей, влияет на отклик пользовательского интерфейса. Показатель сильно зависит от характера работы пользователей. Приведенные оценки справедливы для работы пользователей с основными приложениями, которые оперируют большим количеством параметров, либо большим массивом данных.
Рост мощности среды будет зависеть от той нагрузки, которую должна выдерживать платформа InsparkIoT. В таблице приведены рекомендуемое деление, которое позволяет провести начальную оценку потребности в аппаратных средствах.
Среда POC(proof of concept) используется для тестовых исследований и сред разработки. Среда Small закрывает потребности, например, кампуса/здания. Среды Medium и Large развертываются для действительно большого количества числа объектов, либо высоконагруженного потока измерений.
| Среда | Количество сессий пользователей | Скорость измерений в сек. |
|---|---|---|
| Proof of Concept (POC) | 10 | до 50/сек |
| Small | 50 | до 100/сек |
| Medium | 100 | до 500/сек |
| Large | более 100 | более 500/сек |
Примечание
Внимание! Сведения, приведенные ниже, носят рекомендательный характер, и могут быть применены только в рамках оценки потребностей.
Proof of Concept среда
Рекомендуется установка на локальный сервер в докер-поставке.
Требования к вычислительным ресурсам:
1 сервер:
| vCPU | RAM (Gb) | HDD/SDD (Gb) |
|---|---|---|
| 2 | 16 | 50 |
Совет
Используется магазин виджетов, доступный в облаке Inspark.
Не учитываются ресурсы различных шлюзов (погода, LORAWAN, и т.д.), сервера отчетности, аналитики
Small среда
2 сервера:
| vCPU | RAM (Gb) | HDD/SDD (Gb) | |
|---|---|---|---|
| сервер с приложениями платформы | 4 | 10 | 20 |
| сервер СУБД | 4 | 8 | 200 |
На сервере с приложениями платформы производится установка, как описано в главе Установка ПО на локальный сервер
Совет
Используется магазин виджетов, доступный в облаке Inspark.
Не учитываются ресурсы модулей Inspark Gate, Integration, DataWarehouse
Medium среда
| vCPU | RAM (Gb) | HDD/SDD (Gb) | |
|---|---|---|---|
| сервер с приложениями обработки | 8 | 16 | 20 |
| выделенный сервер СУБД | 8 | 32 | 500 |
| выделенный сервер с MQTT-брокером | 2 | 4 | 50 |
| выделенный сервер REST | 2 | 4 | 20 |
Large среда
Развертывание платформы для больших инсталляций требует высокого уровня готовности сервисов. Поэтому, установка на выделенные серверы для больших сред стандартным способом нами не поддерживается, и требует отдельного проектного решения.
Рекомендуемая инсталляция для больших сред по составу модулей приведена ниже:
- CУБД PostgresSQL - основной узел для хранения метаданных платформы;
- CУБД PostgresSQL - резервный узел для хранения метаданных платформы;
- СУБД Cassandra - не менее 3 узлов для хранения данных. Объем каждого узла кластера Cassandra выбирается с учетом потока данных и требований по глубине хранения;
- Artemis Apache - основной узел шины данных;
- Artemis Apache - резервный узел шины данных;
- MQTT брокер EMQX - два узла в кластере;
- сервисы приложений для обработки данных - количества модулей сервера приложений зависит от величины потока, в среднем необходимо исходить из расчета 20тыс. измерений/сек на один модулей handler и engine, которые поступают от различных Gate модулей.
- сервисы приложений предоставления данных - количества модулей сервера приложений для предоставления данных зависит от количества сессий пользователей, в среднем необходимо исходить из расчета 100 сессий на один модулей webservices.
Мощность хранилища DWH проектируется под объемы ETL выгрузки. см. документацию по Inspark DHW.
Контроль производительности
Контроль основных вычислительных процессов платформы производится по метрикам. Подробно о получении метрик производительности приведено в разделе Мониторинга.
Масштабируемость платформы
Контроль производительности платформы следует проводить через контроль метрик мониторинга.
В случае роста очередей на обработку измерений в шине Artemis, либо недостаточной скорости обработки существуют следующие варианты тюнинга производительности:
- В модуле engine увеличить количество нитей обработки для очереди, которая растет (Measure, Rule). Этот параметр изменяется в конфигурационном файле application.yml.
- Если п.1 не дал результата можно запустить дополнительные экземпляры модуля engine. Модули сами распределят нагрузку через шину. Количество экземпляров engine фактически позволяет почти линейно увеличивать скорость обработки поступающих измерений.
- Если "тормозит" процесс агрегации, то вначале можно увеличить кол-во нитей в модуле engine (см. 1), либо увеличить параметр aggregation.pack_size в application.yml модуля periodic.
- модуль periodic может работать в нескольких экземплярах, распределяю нагрузку по периодическим заданиям между экземплярами через шину. Но, пакеты-задания на выполнение агрегации формирует только один periodic-мастер. Эта роль может переходить к slave узлам при падении master.
- модули GAte могут масштабироваться горизонтально для увеличения скорости обмена.
В случае большого роста БД рекомендуется использовать вариант БД Cassandra, который позволит линейно увеличивать объем хранилища без потери производительности БД.