¶ Рекомендации к аппаратным ресурсам
В разделе даны рекомендации по применению аппаратных и программных сред для работы серверных компонент платформы.
Требования к вычислительным ресурсам в основном определяется 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) |
|---|---|---|
| 4 | 16 | 50 |
Используется магазин виджетов, доступный в облаке Inspark.
Не учитываются ресурсы различных шлюзов (погода, LORAWAN, и т.д.), сервера отчетности, аналитики
¶ Small среда
¶ Локальное равертывание
2 сервера:
| vCPU | RAM (Gb) | HDD/SDD (Gb) | |
|---|---|---|---|
| сервер с приложениями платформы | 4 | 10 | 20 |
| сервер СУБД | 4 | 8 | 200 |
На сервере с приложениеями платформы производится установка в докер-варианте, как описано в главе Установка ПО на локальный сервер
Используется магазин виджетов, доступный в облаке Inspark.
Не учитываются ресурсы различных шлюзов (погода, LORAWAN, и т.д.)
¶ Развертывание в кластере kubernetes
Сервер СУБД развертывается на выделенном сервере с параметрами, указанными выше
| vCPU | RAM (Gb) | HDD/SDD (Gb) |
|---|---|---|
| 4 | 8 | 200 |
В манифесте параметров запуска неодходимо указать значения для переменных ReplicaQuote
replicaQuote:
enabled: true
quoteClass: mini
¶ Medium среда
¶ Выделенная установка
| vCPU | RAM (Gb) | HDD/SDD (Gb) | |
|---|---|---|---|
| сервер с приложениями платформы | 8 | 16 | 20 |
| выделенный сервер СУБД | 8 | 32 | 500 |
| выделенный сервер с MQTT-брокером | 2 | 4 | 50 |
| выделенный сервер nginx | 2 | 4 | 20 |
| выделенный сервер отчетов | 4 | 8 | 50 |
Сервер с приложениями платформы, выделенный сервер отчетов устанавливатеся в докер-поставке. Установка на выделенные серверы СУБД и MQTT брокера описана в в главе Установка ПО на локальный сервер.
¶ Развертывание в кластере kubernetes
Сервер СУБД и брокер MQTT развертывается на выделенном сервере с параметрами, указанными выше
| vCPU | RAM (Gb) | HDD/SDD (Gb) | |
|---|---|---|---|
| выделенный сервер СУБД | 8 | 32 | 500 |
| выделенный сервер с MQTT-брокером | 2 | 4 | 50 |
В манифесте параметров запуска неодходимо указать значения для переменных ReplicaQuote
replicaQuote:
enabled: true
quoteClass: middle
Для quotaClass установлены следующие значения количество реплик сервисов платформы
replicaCount:
# middle
middleQuota_engine: 2
middleQuota_periodic: 1
middleQuota_webservices: 2
¶ Large среда
Развертывание платформы для больших инсталляций как правило требует высокого уровня готовности сервисов. Поэтому, установка на выделенные серверы для больших сред стандартным способом нами не поддерживается, и требует отдельного проектного решения. Рекомендуемая инсталляция для больших сред произодится в кластере kubernetes/OpenShift.
Сервер СУБД и брокер MQTT развертывается на выделенном сервере с параметрами, указанными выше
| vCPU | RAM (Gb) | HDD/SDD (Gb) | |
|---|---|---|---|
| выделенный сервер СУБД - основной | 32 | 128 | 1Tb |
| выделенный сервер СУБД - резерный | 32 | 128 | 1Tb |
| сервер MQTT-кластера-1 | 4 | 8 | 100 Gb |
| сервер MQTT-кластера-2 | 4 | 8 | 100 Gb |
В манифесте параметров запуска неодходимо указать значения для переменных ReplicaQuote
replicaQuote:
enabled: true
quoteClass: large
Для quotaClass установлены следующие значения количество реплик сервисов платформы
replicaCount:
# large
middleQuota_engine: 2
middleQuota_periodic: 2
middleQuota_webservices: 2
При запуск helm-chart сервера приема-передачи, сервисом Redis и Apache Artemis также указываются 2 реплики.
Количество реплик может увеличиваться в зависимости от нагрузки. Метрики производительности и оценка загрузки сервера описана в разделе Производительность.
¶ Оценка производительности
Контроль основных вычислительных процессов платформы производится по метрикам в сервисе graphite.
Сервис Graphite запускается как зависимый helm-chart основного helm-chart semnext.
Для docker варианта, доступ на даш graphite по умолчанию настроен по `http://localhost:8002’
Для варианта развертывания в kubernetes, для просмотра даша graphite следует выполнить следующие команды:
Найти сервис graphite:kubectl get svc -n <Namespace> -o wideПрокинуть порт на локальную машину :
kubectl port-forward -n <Namespace> svc/<graphite сервис> 9999:80Зайти на консоль graphite
http://localhost:9999
Ниже перечислены основные метрики и их описание:
| Метрика | Описание |
|---|---|
| semona.MQTT-messageArrived.mX_rate | скорость поступления измерений на mqtt-брокер за X период (мин) |
| semona.MQTT-signalArrived.mX_rate | скорость поступления сигналов на mqtt-брокер за X период (мин) |
| semona.MQTT-eventArrived.mX_rate | скорость поступления событий на mqtt-брокер за X период (мин) |
| jms-jndi.Measure-commit.mX_rate | скорость обработки измерений в платформе за X период (мин) |
| jms-jndi.Signal-commit.mX_rate | скорость обработки измерений в платформе за X период (мин) |
| jms-jndi.Event-commit.mX_rate | скорость обработки измерений в платформе за X период (мин) |
| jms-jndi.Measure-process.p75 | время обработки в мск 75% всех поступающих измерений |
| jms-jndi.Measure-process.p95 | время обработки в мск 95% всех поступающих измерений |
| jms-jndi.Measure-process.p99 | время обработки в мск 99% всех поступающих измерений |
| jms-jndi.Signal-process.p75 | время обработки в мск 75% всех поступающих сигналов |
| jms-jndi.Signal-process.p95 | время обработки в мск 95% всех поступающих сигналов |
| jms-jndi.Signal-process.p99 | время обработки в мск 99% всех поступающих сигналов |
| REST-* | метрики выполнения rest запросов |
Оценка метрик с точки зрения производительности платформы выполняется следующим образом:
- Показатель semona.MQTT-messageArrived.mX_rate должен быть равен либо не намного (десятые) отличаться от jms-jndi.Measure-commit.mX_rate
Пример на рисунке
- Аналогичная ситуация должна быть по метрикам сигналов и события MQTT-signalArrived, MQTT-eventArrived, Signal-commit, Event-commit
- График скорости обработки измерения не должен иметь очень большой разброс между p75 и p99 (нормально, когда p99 не превышает p75 на порядок). Нельзя указать точные ориентиры по значениям метрик pXX, поскольку эти показатели сильно зависят от производительности вычислителя, типа дисков, скорости сети. Но, если ориентироватьтся на конфигурацию POC, Small, то эти показатели должны быть в районе от 25 до 70 мск.
¶ Масштабируемость платформы
¶ Настройки по маштабируемости платформы
Типовые настройки масштабируемости сопровождаются в helm-charts для запуска платформы в кластере kubernetes (см. раздел выше). В тоже время манифесты запуска содержат переменные replicaCount, в которых можно указать то количество экземпляров реплик, какое необходимо, для каждого модуля.
replicaQuote:
enabled: true
quoteClass: large
replicaCount:
# middle
middleQuota_engine: 2
middleQuota_periodic: 1
middleQuota_webservices: 2
replicaCount:
# large
middleQuota_engine: 2
middleQuota_periodic: 2
middleQuota_webservices: 2
В данном разделе рекомендации по масштабируемости платформы рассматриваются только в контексте повышения производительности обработки и отклика сервиса. Вопросы, связанные с HA, высокой доступности относятся к инфраструктуре вычислительной среды, в частности применения кластера kubernetes, либо подобных решений VM-инфраструктур.
¶ Уровень брокеров приема-передачи измерений
В платформе используются брокеры протоколов MQTT и HTTP/HTTPS. Масштабируемость брокеров достигается последовательным увеличением количества их экземпляров.
Для брокера MQTT справедлива сдедующая схема :
Брокерв EMQX MQTT формируют кластер, где каждый узел связан скаждым. Публикация и подписка производится на любой из узлов. Модуль приема/передачи (на концептуальной схеме он показан как Inspark.Gate) запускается в таком количестве экземпляров, которое требуется для выгребания данных с очередей брокера. Информация о настройке кластера брокера EMQX см. ссылке
Для различных брокера HTTP (на схеме обозначены как Inspark.Gate…(Actility, …)) используется стандартная схема с балансировщиками Http трафика и несколькими экземплярами брокеров.
¶ Уровень обработки данных
На уровне обработке данных масштабируются несколько элементов:
- Шина данных. В качестве шины данных используется Apache artemis, его кластеризацию смотри по ссылке
- Оперативная БД. Оперативная БД построена на БД Redis, его кластеризацию см. по ссылке
- Модули оперативной обработки, входит в состав Inspark.Core
- Модуль периодических заданий, входит в состав Inspark.Core
- БД исторических данных (проект Q421, Apache Cassandra)
Не масштабируется СУБД Postgres, в которой хранится мета-информация и конфигурации инстанса.
Масштабирование шины данных рекомендуется проводить согласованно с масштабированием модуля оперативной обработки. За счет распределения модулей оперативной обработки по брокерам jms-шины увеличивается скорость обмена данными , плюс нагрузка обработки пропорционально распределяется между модулями.
Масштабирование оперативной БД имеет смысл в том случае, если количество параметров огромно и они не могут все поместится в оперативную память машины, где работает Redis. В этом случае применяется классическая схема Redis : N узлов, N/2 - master, N/2 - slave, минимальное кол-во узлов 6.
В большинстве случаев достаточна будет схемы N узлов-мастеров + sentinel, ссылка дана выше.
Модуль периодических заданий выполняет различные сервисные задания. Его масштабирование может потребоваться в том случае, если какие либо задания не будут успевать выполнятьс за оттведенный им период. Масштабирование производится путем запуска дополнительной реплики модуля.
Принципиальная схема выглядит следующим образом
Обозначения на схеме:
M-1, M-2 - узлы Redis (мастер узлы),
S-1,S-2,S-3 - узлы sentinel с кворумом n=2.
¶ Уровень предоставления данных
Модуль RESTAPI, входит в сотав Inspar.Core. Решение по мастабированию использует стандартную схему, куда входит балансировщиr HTTP/HTTPS (используется nginx) и несколько экземпляров модуля RESTAPI.