Control Engineering. Среда исполнения Альфа платформы: Модель резервирования и новые механизмы

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

Полная версия статьи с более детальным описанием механизмов Alpha.Server доступна в журнале Control Engineering №1-2’2024.

Журнал транзакций — основа обновления

Основой обновления Alpha.Server 6.0 стал журнал транзакций — единый высокопроизводительный тракт для обмена любыми событиями между модулями-поставщиками и модулями-потребителями. Через журнал транзакций проходят все события внутри сервера, которые теперь рассматриваются как транзакции.

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

Журнал транзакций сыграл главную роль в последних изменениях на Alpha.Server: на его основе мы реализовали новую модель резервирования и два новых механизма — буферизацию и оперативную таблицу событий.

Новая модель резервирования: Master-Slave репликация

Новая модель резервирования является полноценной Master-Slave репликацией: в ней активный сервер приобретает статус Master, а пассивный — Slave. Журнал транзакций играет роль механизма, с помощью которого реплики согласовывают состояния: он непрерывно реплицируется с Master на Slave и применяет изменения на пассивном сервере, обеспечивая абсолютную идентичность состояний резервной пары.

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

Инициализация

Отправная точка взаимодействия резервной пары — инициализация. Она осуществляется, когда реплики подключаются друг к другу впервые, или после временной потери связи между ними.

Когда серверы резервной пары впервые подключаются друг к другу, Master собирает актуальный срез своего состояния, инициализационные данные, и отправляет его на Slave, обеспечивая постепенное согласование состояний. После этого начинается штатная репликация журнала транзакций — с той позиции, с которой Slave присоединился к Master.

Процесс инициализации, осуществляемый после восстановления связи между резервной парой, необходим для согласования состояния реплик (рис. 2). Важно отметить, что во время инициализации работа Master не останавливается: он продолжает прием данных и обработку событий.

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

Приоритет как основа резервного перехода

Приоритет — это характеристика, которая распределяется парой реплицируемых серверов самостоятельно по критериям связи с полем и времени старта или задается администратором вручную. Реплика, обладающая приоритетом, будет стремиться оставаться в состоянии Master, а неприоритетная — в Slave.

Резервный переход в новой модели исполнения является операцией передачи приоритета. Рассмотрим, как этот процесс происходит в двух возможных случаях: штатном и нештатном.

Штатный резервный переход происходит, когда оператор вручную переназначает приоритет реплик. В этом случае Master последовательно переходит в Slave, а Slave в Master, причем во время резервного перехода бывший Master не прекращает передачу событий журнала транзакций. Когда бывший Slave завершит переход к состоянию Master, он начнет обрабатывать транзакции с позиции, следующей за последней обработанной парным сервером (рис. 3).

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

Нештатный резервный переход осуществляется, когда Slave теряет связь с Master. В этом случае Slave переходит в режим «аварийного» Master и начинает обрабатывать транзакции. Если отсутствие связи вызвано сбоем соединения, обе реплики выполняют независимые вычисления. Данные могут дублироваться, однако потери сводятся к нулю. Если произошел сбой в работе Master, то потери ограничиваются временем определения отсутствия связи между репликами.

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

Детальная статистика

Новая транзакционная модель позволяет предоставлять больший объем информации о состоянии пары реплицируемых серверов. Оценить состояние реплик дает возможность «статус аварии», важный для конечных пользователей Альфа платформы.

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

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

Буферизация

Одной из основных производных журнала транзакций и новой модели исполнения стал механизм буферизированной передачи потока данных между узлами Alpha.Server, осуществляемый по модели «источник-потребитель». Механизм отвечает за сохранность актуальных данных в случае временной потери связи между отдельными экземплярами сервера — узлами, выступающими в роли источников и потребителей буферизируемых данных.

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

Механизм буферизации, схематично показанный на рис. 5, осуществляется по следующему алгоритму:

1. На содержимое буфера узла-источника подписываются узлы-потребители, которых может быть несколько 
2. При создании подписки для потребителей в буфере определяется позиция, с которой начинается чтение 
3. Узлы-потребители получают срез буферизованных данных, актуальных для позиции в буфере, к которой было произведено подключение 
4. Начинается штатное чтение буфера; его данные стираются после того, как их получат все подписавшиеся узлы-потребители

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

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

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

Буферизация — это принципиально новый, но важный механизм в Alpha.Server. При его реализации мы придерживались следующих принципов:

• Минимизация использования оперативной памяти — если потребителя нет на связи долгое время, буфер не будет занимать ОЗУ поставщика, так как его содержимое хранится локально на диске 
• Устойчивость к перезагрузкам — данные для потребителя сохраняются на жестком диске, а значит, останутся доступны после перезагрузки сервера
• Единый порядок данных на поставщике и потребителе — события сохраняются и читаются в буфере с соблюдением единого строгого порядка и в том же порядке передаются подписчикам
• Обеспечение полноты данных на потребителе — при временном разрыве и восстановлении связи позиция подписчика сохраняется, и он продолжает читать буфер с того же места

Алгоритмы буферизации в схемах без резервирования и с резервированием Master и/или Slave подробно описаны в полной версии статьи.

Оперативная таблица событий

Следующим механизмом, реализованным на основе новой транзакционной модели, стала оперативная таблица событий (Operative Alarm Table, OAT). Рассмотрим, какую роль играет OAT, на примере активаций абстрактного датчика Sensor A, который срабатывает при достижении определенного порога значений (Hi_Level).

На рис. 6, иллюстрирующем принцип работы OAT, видно, что за время наблюдения произошло три срабатывания, два из которых уже не активны. Без OAT клиент увидит только последнюю активацию, которая произошла в момент времени T₃, а предыдущие события не отобразятся, хотя они остались не квитированы. В случае перезапуска сервера исчезнут вообще все срабатывания: их все еще можно будет получить из истории активаций, но в наборе актуальных событий они не отобразятся.

OAT позволяет увидеть все актуальные события — активные или неквитированные. Таблица будет выводить срабатывания сенсора в моменты T₁, T₂ и T₃, пока пользователь не отреагирует на них. Информация об активациях хранится на жестком диске, а значит, будет доступна и после перезапуска сервера. При этом в оперативной памяти удерживаются лишь небольшие индексные блоки, поэтому даже большое количество событий не приведет к существенному возрастанию потребления ОЗУ.

В условиях репликации у каждого из резервируемых серверов есть своя копия OAT. На этапе инициализации Master передает OAT на Slave, и тот замещает собственную таблицу полученной. Так и достигается начальная идентичность OAT резервной пары. Дальнейшее согласование OAT резервной пары, продемонстрированное на рис. 7, обеспечивается штатной репликацией журнала транзакций.

Заключение

Описанные в статье нововведения, затронувшие среду исполнения Альфа платформы:

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

В дальнейших планах — развитие модели резервирования, в частности поддержка N-кратной репликации

Источник: «Среда исполнения Альфа платформы: новые механизмы и модель резервирования», Control Engineering Россия, июнь 2024.