Планирование архитектуры

В этом разделе даются некоторые советы по планированию и проектированию архитектуры развертывания AggreGate. В частности, здесь рассказывается о том, как распределить системные функции между отдельными серверами и построить надежную высокопроизводительную передачу данных между ними.

Обратите внимание, что AggreGate - сложная платформа, и высоконагруженные приложения, созданные на ее основе, не будут идеальными, если опираться на стереотипные шаблоны, описанные здесь. Каждая высоконагруженная архитектура требует тщательного продумывания. Мы рекомендуем партнерам и клиентам AggreGate поддерживать связь с командой Tibbo для проверки сложных архитектур.

Отдельные экземпляры серверов AggreGate, расположенные на физических серверах, в виртуальных машинах и контейнерах, являются основными компонентами каждой инсталляции AggreGate. Чтобы упростить проектирование архитектуры и планирование стоимости лицензий, мы предлагаем разделить серверы на несколько ролей. В каждой роли может быть один или несколько серверов - например, в типичном сценарии проектирования используется несколько серверов с ролью пограничного сервера и один сервер с ролью основного сервера.

В любом месте этого раздела, когда мы говорим об экземпляре сервера AggreGate, мы подразумеваем отдельный сервер или отказоустойчивый кластер, включающий два или более серверов. С архитектурной точки зрения отказоустойчивый кластер действует как один сервер, только устойчивый к локальным аппаратным и программным сбоям.

Любое увеличение количества серверов в инсталляции AggreGate, как и для любого другого программного обеспечения, означает усложнение системы и увеличение затрат на развертывание и администрирование. Поэтому всегда важно найти правильный баланс между монолитной и микросервисной архитектурой.

Строго говоря, существует всего несколько фундаментальных причин для разделения функциональности на несколько серверов AggreGate:

• Географическое распределение устройств, источников данных и точек размещения серверов (т. е. центров обработки данных и диспетчерских комнат/шкафов)

• Ограничения ресурсов каждого отдельного сервера, в основном количество ядер процессора и объем оперативной памяти, а также локальное дисковое пространство и пропускная способность сети

• Способность сервера "микросервиса" продолжать работу в то время, когда соседние микросервисы не работают, перезапускаются или переходят в режим обхода отказа.

Давайте обсудим эти причины по отдельности.

Если ваши устройства находятся далеко от основного центра обработки данных, часто целесообразно установить выделенные серверы AggreGate рядом с устройствами. Это могут быть "чистые" пограничные серверы, работающие на промышленных ПК или пограничных шлюзах, или обычные физические серверы и даже виртуальные машины, расположенные в серверной стойке или небольшой комнате управления удаленного объекта.

Сервер, расположенный географически близко к устройствам, дает несколько преимуществ:

• Локальный опрос и управление устройствами может осуществляться в локальном изолированном сегменте сети по протоколам, которые не обладают достаточной безопасностью и не выдерживают длительных отключений сети, как, например, большинство протоколов промышленной автоматизации.

• Собранные данные могут буферизироваться, фильтроваться, шифроваться и сжиматься перед отправкой на сервер более высокого уровня.

• В некоторых случаях "сырые" данные устройства фактически никогда не отправляются на другой сервер, а обрабатываются локально, и только ценные изменения и события передаются "наверх".

Вот несколько примеров геораспределенного расположения серверов:

• Изолированный удаленный объект без людей с промышленным пограничным шлюзом, например насосная станция или автономный электрический трансформатор.

• Цех, солнечная ферма или автозаправочная станция, где есть персонал для выполнения рутинных операций, но нет квалифицированных инженеров для расследования программных инцидентов и внесения серьезных изменений в конфигурацию.

В системах с высокой нагрузкой любой "центральный" сервер обычно участвует в обработке миллионов или даже миллиардов событий в день, поступающих от тысяч устройств и источников данных, подключенных прямо или косвенно.

Это означает, что устойчивая нагрузка на такой сервер обычно довольно высока, но в то же время достаточно стабильна, поскольку устройства обычно предоставляют выборки данных через фиксированные промежутки времени.

В то же время люди-операторы, работающие с вашим IoT/IIoT-продуктом или решением, часто могут создавать огромные скачки нагрузки, особенно во время расследования инцидента, который заставляет обычных пользователей продукта и даже системных администраторов запускать различные отчеты и просматривать огромные объемы исторических данных.

Если сервер "с лицом устройства", работающий с высокой устойчивой нагрузкой (например, с высокой загрузкой процессора и использованием памяти), будет затронут таким "всплеском человеческих действий", он может не продолжить необходимые операции мониторинга и управления, пропуская новые важные события и ситуации, связанные с парком устройств.

Поэтому для высоконагруженных систем мы обычно рекомендуем разделять функции "device-faced" и "human-faced" на отдельные AggreGate серверы:

• Серверы, обращенные к устройствам, отвечают за прямой или косвенный (через серверы нижнего уровня) сбор, хранение и базовую обработку данных об устройствах (фильтрация, обогащение, оповещение и т. д.).

• Серверы, ориентированные на человека, выполняют операции, инициируемые пользователями и операторами через пользовательский интерфейс вашего продукта или решения, например, загрузка и обработка исторических наборов данных, заполнение печатных отчетов, подготовка данных для сложных информационных панелей и т. д.

Существуют также операции, потребляющие значительное количество ресурсов, но привязанные к входящим потокам данных устройства. Примерами таких операций могут быть использование обучаемых модулей на основе ML, сложная обработка событий или обнаружение топологии сети.

Мы рекомендуем хранить такие операции на серверах, обращенных к устройствам, поскольку они обычно не вызывают высоких и непредсказуемых скачков нагрузки. Однако в очень высоконагруженных системах такие операции могут выполняться сервером(ами) с выделенной ролью "расширенная обработка данных устройств".

В классической микросервисной архитектуре каждый микросервис должен продолжать работу, пока соседние микросервисы не работают в течение короткого (а иногда и длительного) периода времени.

В случае с IoT/IIoT-продуктом каждый микросервис должен обмениваться информацией с соседними микросервисами на очень высокой скорости, часто несколько миллионов взаимодействий в секунду. Представьте, что у вас есть 10 000 устройств с 10 метриками на каждом, которые опрашиваются с частотой 1 Гц. Есть также 10 простых оповещений, каждое из которых проверяет все метрики с той же частотой 1 Гц, просто чтобы убедиться, что они соответствуют определенным сложным критериям, и обнаружить неисправность без задержки, чтобы сообщить о ней операторам системы. В этом случае количество проверок в секунду составит 10 000 x 10 x 10 = 1 000 000 проверок в секунду. Если устройства и модуль оповещений находятся на одном сервере AggreGate, каждая проверка - это простая ссылка на объект в памяти, которая обходится практически без затрат. Если же устройства и оповещения разнесены по разным серверам AggreGate, то каждая проверка будет сопровождаться запросом по локальной сети, который включает в себя сериализацию/десериализацию данных, шифрование/дешифрование, передачу через сетевой стек операционной системы и даже ненулевую задержку в сети. Независимо от протокола, используемого для связи между серверами (будь то протокол AggreGate или HTTP/REST), и даже если платформе удастся "агрегировать" 1 миллион проверок в несколько тысяч отдельных сетевых операций, дополнительная нагрузка на систему, вызванная этой довольно простой проверкой предупреждений, будет достаточно высокой, чтобы отнять значительное количество ресурсов у обоих "разделенных" серверов.

Более того, в отличие от обычных микросервисов, AggreGate обеспечивает активно-пассивную и активно-активную отказоустойчивую кластеризацию, обеспечивая высокую доступность каждого отдельного сервера и позволяя минимизировать периоды его простоя.

Поэтому мы, как правило, не рекомендуем разделять функциональность между серверами AggreGate только ради повышения доступности.

Вместо этого каждый AggreGate-сервер, роль которого предполагает, что во время его простоя пострадает работа всей системы, должен быть реализован в виде активно-пассивного или активно-активного отказоустойчивого кластера.

Активно-пассивная отказоустойчивость не требует архитектурного планирования. Просто установите второй экземпляр отказоустойчивого сервера рядом с основным, и время простоя, как правило, будет ограничено десятками секунд (или максимум несколькими минутами, в очень редких случаях).

Активно-активное обход отказов требует предварительного тщательного проектирования архитектуры приложения и установки одного или нескольких серверов-координаторов кластера обхода отказов. Однако это окупается тем, что время простоя ограничивается несколькими секундами. Это вполне приемлемо для любых продуктов и решений IoT/IIoT.

В AggreGate у вас есть огромное количество опций, которые позволяют передавать данные и выполнять операции управления с одного сервера на другой. Этот раздел поможет сделать правильный выбор, какой метод подключения к серверу использовать.

В принципе, все методы соединения сервера с сервером делятся на три группы:

• Первый сервер выступает в качестве источника данных, запуская специальное устройство Local Agent, а другой сервер получает данные от первого сервера через драйвер устройства Agent.

• Первый сервер выступает в качестве сервера-провайдера, а второй - в качестве сервера-потребителя в распределенной архитектуре AggreGate.

• Два сервера AggreGate обмениваются информацией с помощью сторонней технологии, которая поддерживается AggreGate как со стороны "сервера-отправителя", так и со стороны "клиента-потребителя". К таким технологиям относятся MQTT, HTTP, Kafka, OPC, IEC-104 или другие протоколы.

Платформа AggreGate разработана таким образом, что все случаи соединения сервера с сервером могут быть успешно охвачены первыми двумя сценариями (локальная пара агент/агент и распределенная архитектура), которые оба полагаются на протокол AggreGate для установления безопасных, сжатых, буферизованных и высокоэффективных серверных соединений с гарантированной доставкой. Соединения, использующие сторонние протоколы, доступны по усмотрению партнера/клиента, но обычно не дают никаких дополнительных преимуществ.

Приведенная ниже таблица поможет выбрать подходящий метод связи между серверами:

Обратите внимание, что во многих случаях оба метода подключения могут использоваться параллельно. В этом случае соединение Local Agent - Agent используется для передачи данных устройства между серверами AggreGate, а соединение распределенной архитектуры позволяет пересылать конфигурацию и операции управления.

К этому моменту вы уже знаете количество и роли экземпляров серверов AggreGate в вашей системе. Настало время оценить системные требования для каждого сервера/VM/контейнера, и в первую очередь количество ядер процессора, объем оперативной памяти и дискового пространства.

Раздел " Требования " в документации AggreGate Server содержит подробные рекомендации по оценке параметров сервера.

Однако, к сожалению, из-за сложности решений, построенных на базе AggreGate, не существует прямого способа точно рассчитать требуемые ресурсы. Это похоже на разработку с использованием классических стеков технологий (например, Java + JavaScript), где требуемые ресурсы являются очень сложной функцией качества кода и нагрузки на систему. Аналогично, производительность ваших серверов может существенно зависеть от фактической логики вашего приложения. Для обеспечения высокой производительности решения может потребоваться оптимизация производительности, например, кэширование промежуточных получаемых/вычисляемых значений.

Вот еще несколько подсказок, которые могут быть полезны при оценке ресурсов:

• Количество требуемых ядер процессора в наибольшей степени коррелирует с количеством событий, обрабатываемых ядром AggreGate Server. Чтобы оценить количество этих событий, помните, что изменение переменной - это тоже событие. Таким образом, учитывайте события и изменения значений переменных, генерируемые локальными учетными записями устройств, события и изменения значений, перенаправляемые с других серверов, а также события и изменения значений переменных, генерируемые локально (например, моделями, корреляторами и т. д.).

• Объем требуемой оперативной памяти в наибольшей степени зависит от количества контекстов на вашем сервере. Каждый контекст, будь то контекст устройства, контекст модели или контекст пользователя, представляет собой сложный объект с внутренними кэшами, очередями и другими чувствительными к памяти элементами. Поэтому серверы с 10 и 100 000 устройств будут требовать разного объема оперативной памяти, даже если общее количество событий в секунду, генерируемых этими парками устройств, примерно одинаково.

• Объем дискового пространства, требуемый самой системой AggreGate Server, невелик. Если вкратце, то для размещения самого сервера достаточно любого современного SSD-накопителя объемом несколько сотен гигабайт. Однако хранилищу AggreGate требуется объем дискового пространства, сильно коррелирующий с количеством исторических событий и изменений значений, настроенных на постоянное хранение, а также сроком хранения (истечения) и размером каждой выборки данных. Таким образом, чтобы получить очень краткую оценку требуемого пространства для хранения данных, умножьте количество постоянных ежедневных событий на длительность периода хранения (очевидно, в днях) и на средний размер дискового следа каждой выборки. Размер этого следа составляет несколько сотен байт для простых событий/изменений со скалярными значениями, но может вырасти до нескольких килобайт, если образцы данных содержат табличную или иерархическую полезную нагрузку, например, JSON-документы. Не забывайте, что требования к дисковому пространству относятся к серверу, на котором работает выбранный движок базы данных, а это не обязательно серверная машина AggreGate.

Как правило, хорошим решением будет увеличить объем ресурсов, оцененных в соответствии с рекомендациями раздела " Требования", в случае, если бюджет проекта не позволяет запросить дополнительные ресурсы на более поздних этапах реализации системы. Чем сложнее дизайн системы, тем выше должен быть процент запрашиваемых дополнительных ресурсов для снижения возможных рисков, связанных с узкими местами в производительности.

Несмотря на то что архитектура каждого продукта и решения на базе AggreGate уникальна, существуют типичные шаблоны проектирования и реализации, общие для многих решений. В частности, есть несколько типичных ролей AggreGate Server, которые подразумевают определенные функции в рамках всей системы и определенные возможности, используемые для обеспечения их работоспособности.

Вот наиболее часто используемые роли сервера:

• Сервер "все в одном". Это один AggreGate сервер, на котором размещается все IoT-решение или продукт. Он охватывает все аспекты работы системы, начиная от связи с устройствами и заканчивая хостингом пользовательских подключений через встроенный веб-сервер. В большинстве случаев сервер "все в одном" хранит данные через встроенную базу данных. В других случаях сервер базы данных работает на отдельной машине.

• Сервер коллектора. Это довольно типичная роль сервера AggreGate, работающего на пограничном шлюзе IoT или на обычной машине, расположенной непосредственно рядом с устройствами. Collector выполняет обмен данными с устройствами через различные драйверы, но обычно не хранит данные локально. Вместо этого данные направляются на другой сервер (обычно установленный в центре обработки данных) через драйвер Local Agent, который использует буферизацию для обработки сбоев связи. Сервер коллектора может управляться и настраиваться как централизованно через распределенную архитектуру, так и локально через встроенный веб-сервер. Иногда сервер-сборщик называют сервером-зондом, поскольку он может выполнять операции мониторинга в своем локальном сегменте сети и загружать данные измерений в облако.

• Сервер хранения данных. Сервер хранения - это своего рода концентратор, который получает данные от коллекторов/зондовых серверов, предварительно агрегирует их и сохраняет в какой-либо высокопроизводительной базе данных. Поскольку серверы хранения часто используются в высоконагруженных установках, сервер хранения, скорее всего, будет использовать внешний кластер баз данных, а не встроенный экземпляр базы данных.

• Аналитический сервер. Такой сервер обычно отвечает за анализ данных с помощью машинного обучения, обработки сложных событий, языка запросов AggreGate и других модулей расширенной аналитики. Он может выполнять анализ "на лету", получая потоки данных с устройств непосредственно от коллекторов/зондов или перенаправляя их с сервера хранения. Аналитический сервер может хранить большие наборы данных для анализа в памяти или периодически загружать их из хранилища. Обработанные данные (результаты) также могут быть сохранены в памяти для быстрого представления в пользовательских интерфейсах операторов или сохранены в базе данных.

• Веб-сервер. Сервер в этой роли - это прежде всего хостинг встроенного движка веб-сервера. Он может выступать в качестве автономного веб-сервера, отвечая только за обслуживание веб-соединений операторов и перенаправляя все операции на другие серверы. В других случаях это может быть более "обычный" AggreGate сервер, сочетающий в себе хостинг сеансов веб-пользователей и некоторые другие виды деятельности.

• Основной узел кластера Hozirontal, узел-координатор, сервер приложений и сервер входа в систему. Эти роли серверов специфичны для архитектуры развертывания горизонтального кластера. Целью горизонтального кластера является обеспечение неограниченной автоматической хозиронтальной масштабируемости системы за счет бессерверной архитектуры. Очень упрощенная версия горизонтального кластера (с двумя основными узлами и одним или двумя узлами-координаторами) позволяет реализовать сценарий активного обхода отказа. Дополнительные сведения об этих ролях серверов см. в разделе " Горизонтальный кластер " и в учебнике "Настройка серверов для активного об хода отказа".

Обратите внимание, что каждый сервер AggreGate в распределенной установке может иметь две независимые роли: функциональную роль (одну из описанных выше или собственную) и роль обхода отказа (т. е. ведущий или ведомый для сценария активно-пассивного обхода отказа). Например, отказоустойчивый ведущий сервер-коллектор выполняет роль узла сбора данных, но если он по какой-либо причине не работает, его функциональность будет поддерживать отказоустойчивый ведомый сервер-коллектор.

В этом разделе описаны наиболее типичные архитектуры развертывания AggreGate. Большинство продуктов и решений на базе платформы используют одну из приведенных ниже архитектур в неизменном или слегка измененном виде. Лишь относительно небольшой процент крупномасштабных и высоконагруженных продуктов/решений требует разработки и реализации уникальных архитектурных схем.

Это самая простая из возможных архитектур развертывания AggreGate. Она единственная, для которой требуется один физический сервер или виртуальная машина. Однако благодаря высокой эффективности платформы она позволяет реализовывать достаточно сложные продукты/решения с достаточно высокой нагрузкой.

Схема развертывания включает в себя сервер или виртуальную машину, на которой работает как AggreGate сервер, так и движок базы данных. Последний обычно работает во встроенном формате, не требуя специальных усилий по развертыванию и администрированию.

Поскольку в данном случае не реализован метод обхода отказа, такая установка требует соответствующей политики резервного копирования и восстановления.

Эта схема развертывания требует наличия двух серверов/VM - одного для экземпляра сервера AggreGate и другого для экземпляра движка базы данных. Обе машины должны быть расположены в одном центре обработки данных и соединены высокоскоростной сетью (1 Гбит/с или выше) из-за высокой интенсивности обмена данными между сервером AggreGate и его базой данных.

В этом сценарии требования к дисковому пространству должны предъявляться к серверу хранения данных. На серверной машине AggreGate следует использовать высокоскоростное хранилище с SSD-накопителем, обеспечивающее более быстрый запуск.

Несмотря на использование двух серверов, в данной схеме развертывания не реализован метод обхода отказа. Она требует правильной политики резервного копирования и восстановления.

В этой схеме используются два кросс-функциональных физических сервера или виртуальные машины, на которых совместно работают экземпляр сервера AggreGate и экземпляр движка базы данных.

Экземпляры сервера AggreGate, работающие на обеих машинах, являются членами активно-пассивного кластера обхода отказа: один из них является главным узлом, а другой - узлом обхода отказа.

Два экземпляра движка базы данных, расположенные на одних и тех же машинах, являются узлами кластера обхода отказов для конкретной базы данных. Например, если используется база данных Apache Cassandra, серверы Cassandra реплицируют (зеркалируют) все данные между собой, обеспечивая защиту от сбоев хранилища. В этом случае требования к дисковому пространству должны предъявляться к каждой из серверных машин (и фактически удваиваются).

Для этого сценария требуется четыре сервера/VM. Это высокодоступная установка AggreGate, способная справиться с самой высокой нагрузкой, которую можно выдержать без разделения ролей серверов, расположенных в одном центре обработки данных.

Единственное отличие от описанного выше сценария заключается в том, что каждый экземпляр AggreGate и сервера базы данных занимает отдельную машину. Отсутствие разделения ресурсов CPU/RAM между AggreGate и его механизмом хранения обеспечивает более высокую общую производительность, особенно во время скачков нагрузки, возникающих при запуске системы, массовом переподключении устройств после сбоя сети или одновременной ресурсоемкой деятельности или нескольких пользователей/операторов.

Активно-активный обход отказа - это передовая технология, основанная на горизонтальном кластереAggreGate. Позволяя сократить время простоя при сбоях с десятков секунд до считанных секунд, она требует тщательного (и порой непростого) планирования и адаптации архитектуры вашего продукта/решения к довольно сложной реальности парадигмы горизонтальной кластеризации.

Архитектура активно-активного отказоустойчивого кластера строится либо из двух узлов Active-Passive Failover Cluster, либо из четырех узлов High-load Active-Passive Failover Cluster, в зависимости от ожидаемой нагрузки на систему. Один или два сервера/ВМ Cluster Coordinator добавляются к описанным выше структурам узлов, формируя следующий список вариантов:

• 3-узел: два общих сервера базы данных AggreGate+ и сервер координатора кластера без поддержки

• 4-узел: две общие машины AggreGate+базы данных и два реплицированных сервера-координатора кластера

• 5-узел: два AggreGate-сервера, два сервера баз данных и не поддерживаемый сервер-координатор кластера

• 6-узел: два AggreGate-сервера, два сервера баз данных и два реплицированных сервера-координатора кластера

Это географически распределенный сценарий развертывания с двумя ролями серверов: один или несколько серверов коллекторов/зондов и один центральный сервер.

Очень важно понимать значение сервера здесь и в других сценариях распределенного развертывания. Сервер с определенной ролью - это логический элемент схемы развертывания, который может быть представлен несколькими физическими серверами или виртуальными машинами, развернутыми в одном из описанных выше сценариев: от монолитного до активного отказоустойчивого кластера (Active-Active Failover Cluster). Таким образом, сервер многоролевой распределенной установки может включать в себя от одного до шести физических или виртуальных серверных машин.

В этом двухуровневом сценарии центральный сервер обычно устанавливается в основном центре обработки данных компании, а серверы коллекторов/зондов располагаются рядом с устройствами, которые они контролируют или обслуживают.

Серверы коллекторов/зондов обычно представляют собой установки монолитного типа AggreGate, работающие на шлюзах Edge, промышленных ПК или обычных физических серверах, установленных в серверной стойке на удаленном объекте.

Однако в некоторых случаях серверы коллектора/зонда также являются высоконагруженными серверами, установленными во вторичных центрах обработки данных компании, которые обслуживают определенные части крупной промышленной/IT-инфраструктуры. В этом случае коллекторные/зондовые серверы могут использовать схемы "сервер платформы + сервер хранения", "активно-пассивный отказоустойчивый кластер", "активно-пассивный отказоустойчивый кластер" или "активно-активный отказоустойчивый кластер".

Центральный сервер такой двухуровневой установки обычно испытывает высокие нагрузки и нуждается в высокой доступности. В то же время этот сервер не участвует в мониторинге в режиме близком к реальному времени, промышленном диспетчерском управлении или других операциях, чувствительных ко времени. Поэтому развертывание его в сценарии активного обхода отказа нецелесообразно.

Поэтому для центрального сервера обычно используется архитектура развертывания "Active-Passive Failover Cluster" или "High-load Active-Passive Failover Cluster".

Очевидным узким местом сценария развертывания Distributed Two-Tier является его центральный сервер. В большой системе с несколькими сотнями тысяч устройств центральный сервер должен обрабатывать до миллиона или даже миллионов событий в секунду.

В системах такого масштаба центральный сервер должен быть разделен на несколько ролей, либо на некоторые из описанных выше (сервер хранения, сервер аналитики, веб-сервер), либо на собственные.

Обратите внимание, что каждый сервер в этом сценарии - это еще и логический элемент системы, который может поддерживаться одной или несколькими физическими или виртуальными машинами, развернутыми в той или иной вариации, от монолитной до высоконагруженного активно-пассивного отказоустойчивого кластера. Активно-пассивный обход отказа нецелесообразен для центральных серверов, поскольку они не задействованы в операциях в режиме близком к реальному времени. Его все же можно реализовать, но в большинстве случаев это будет серьезным перебором.

Горизонтальный кластер - наиболее продвинутый сценарий развертывания AggreGate. Это бессерверная архитектура, позволяющая автоматически масштабировать AggreGate установку с неограниченным количеством устройств и пользователей.

Из-за своей сложности архитектура горизонтального кластера должна планироваться в сотрудничестве с командой Tibbo.

Технология кластеризации Hozirontal описана в отдельном разделе.